Re: Bitmap index scans use of filters on available columns - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Bitmap index scans use of filters on available columns
Date
Msg-id 563D41BD.8050207@2ndquadrant.com
Whole thread Raw
In response to Re: Bitmap index scans use of filters on available columns  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Bitmap index scans use of filters on available columns  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 11/05/2015 07:36 PM, Robert Haas wrote:
> On Thu, Nov 5, 2015 at 1:29 PM, Tomas Vondra
> <tomas.vondra@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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan
Next
From: Peter Geoghegan
Date:
Subject: Re: Using quicksort for every external sort run