Re: Index INCLUDE vs. Bitmap Index Scan

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Index INCLUDE vs. Bitmap Index Scan
Дата
Msg-id 20190226232937.4zo5p5booaffy7g6@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Index INCLUDE vs. Bitmap Index Scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-02-26 18:22:41 -0500, Tom Lane wrote:
> 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
onmaster as 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.

We could probably work around that, by only doing such pre-checks on
index tuples only for tuples known to be visible according to the
VM. Would quite possibly be too hard to understand for users
though. Also not sure if it'd actually perform that well due to the
added random IO, as we'd have to do such checks before entering a tuple
into the bitmap (as obviously we don't have a tuple afterwards).

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Autovaccuum vs temp tables crash
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Segfault when restoring -Fd dump on current HEAD