Re: [HACKERS] partial indexes and bitmap scans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] partial indexes and bitmap scans
Date
Msg-id 24648.1489080325@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] partial indexes and bitmap scans  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] partial indexes and bitmap scans  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> We have already figured out that the user's predicate results in a
> subset of the index's or we wouldn't be able to use that index though,
> right?  Do we really need to spend cycles re-discovering that?  Are
> there cases where we actually need the index's predicate to ever be
> included for correctness..?

In a bitmap indexscan, yes, because the entire point of the recheck
condition is that we're going to scan a whole page and possibly see
tuples that don't satisfy the index predicate at all.  Another point
that's mentioned in the comments in createplan.c is that if you're
considering the result of a BitmapOr or BitmapAnd, there's not necessarily
a single index involved so it's much harder to reason about which part
of the qual is an index predicate.

I do notice that createplan.c makes some effort to get rid of filter
conditions that are provably true when the index conditions are.
Doesn't look like it considers the reverse direction.  Not sure if
that's missing a bet.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Parallel Bitmap scans a bit broken
Next
From: Mark Dilger
Date:
Subject: Re: [HACKERS] use SQL standard error code for nextval