On 10/31/2018 10:07 PM, David Rowley wrote:
> On 1 November 2018 at 05:40, Robert Haas <robertmhaas@gmail.com> wrote:
>> This kinda reminds me of commit
>> 8f9fe6edce358f7904e0db119416b4d1080a83aa. We needed a way to provide
>> the planner with knowledge about the behavior of specific functions.
>> In that case, the specific need was to be able to tell the planner
>> that a certain function call could be omitted or strength-reduced, and
>> we did that by having the planner call a function that encoded the
>> necessary knowledge. Here, we want to evaluate a function call and
>> see whether it is order preserving, which could depend on a whole
>> bunch of stuff that isn't easily parameterized by catalog entries, but
>> could be figured out by a C function written for that purpose. I'm
>> not really sure how that would work in this case, or whether it's a
>> good idea, but I thought I'd mention it just in case it's helpful.
>
> Agreed. That's a good idea. Thanks.
>
FWIW this is mostly what I had in mind when referring to the selectivity
estimation functions for operators, although I now realize it might not
have been explained very clearly.
Anyway, I agree this seems like a much better way than trying to store
all the potentially relevant meta-data in catalogs.
I still have trouble imagining what exactly would the function do to
determine if the optimization can be applied to substr() and similar
collation-dependent cases.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services