Re: Index INCLUDE vs. Bitmap Index Scan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Index INCLUDE vs. Bitmap Index Scan
Date
Msg-id 16218.1551223361@sss.pgh.pa.us
Whole thread Raw
In response to Index INCLUDE vs. Bitmap Index Scan  (Markus Winand <markus.winand@winand.at>)
Responses Re: Index INCLUDE vs. Bitmap Index Scan
Re: Index INCLUDE vs. Bitmap Index Scan
List pgsql-hackers
Markus Winand <markus.winand@winand.at> writes:
> I think Bitmap Index Scan should take advantage of B-tree INCLUDE columns, which it doesn’t at the moment (tested on
masteras of yesterday). 

Regular index scans don't do what you're imagining either (i.e., check
filter conditions in advance of visiting the heap).  There's a roadblock
to implementing such behavior, which is that we might end up applying
filter expressions to dead rows.  That could make users unhappy.
For example, given a filter condition like "1.0/c > 0.1", people
would complain if it still got zero-divide failures even after they'd
deleted all rows with c=0 from their table.

Generally speaking, we expect indexable operators not to throw
errors on any input values, which is why this problem isn't serious
for the index conditions proper.  But we can't make that assumption
for arbitrary filter conditions.

> (As a side node: I also dislike it how Bitmap Index Scan mixes search conditions and filters in “Index Cond”)

What do you think is being mixed exactly?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [Patch][WiP] Tweaked LRU for shared buffers
Next
From: Benjamin Manes
Date:
Subject: Re: [Patch][WiP] Tweaked LRU for shared buffers