Hi,
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.
regards
--
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:
http://www.postgresql.org/mailpref/pgsql-hackers
