On 10/31/2018 10:07 PM, David Rowley wrote: > On 1 November 2018 at 05:40, Robert Haas <robertmh...@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
