On 11/05/2015 07:36 PM, Robert Haas wrote:
On Thu, Nov 5, 2015 at 1:29 PM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:

But then again, can we come up with a way to distinguish operators that are
safe to evaluate on indexes - either automatic or manual? We already do that
with the indexable operators with explicitly listing them in the opclass,
and we also explicitly use the LEAKPROOF for a similar thing. I don't think
extending the opclass is a really good solution, but why not to invent
another *PROOF flag?

I think LEAKPROOF is probably fine for this.  How would the new thing
be different?

I don't think so - AFAIK "leakproof" is about not revealing information about arguments, nothing more and nothing less. It does not say whether it's safe to evaluate on indexes, and I don't think we should extend the meaning in this direction.

I find it perfectly plausible that there will be leakproof functions that can't be pushed to indexes, and that would not be possible with a single marker. Of course, "leakproof" may be a minimum requirement, but another marker is needed to actually enable pushing the function to index.

Of course, we may eventually realize that leakproof really is sufficient, and that we can push all leakproof functions to indexes. In that case we may deprecate the other marker and just use leakproof. But if we go just with leakproof and later find that we really need two markers because not all leakproof functions are not index-pushable, it'll be much harder to fix because it will cause performance regressions for the users (some of the expressions won't be pushed to indexes anymore).

But I think the marker is the last thing we need to worry about.


Tomas Vondra                   http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to