Re: Use of additional index columns in rows filtering

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: James Coleman <jtc331(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Maxim Ivanov <hi(at)yamlcoder(dot)me>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, markus(dot)winand(at)winand(dot)at
Subject: Re: Use of additional index columns in rows filtering
Date: 2023-08-17 23:29:56
Message-ID: 1368005e1e475e40cf0420708c57b00cac59a181.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2023-08-09 at 17:14 -0700, Peter Geoghegan wrote:
> + Index quals are better than equivalent index filters because bitmap
> index scans can only use index quals

It seems there's consensus that:

* Index Filters (Tomas's patch and the topic of this thread) are more
general, because they can work on any expression, e.g. 1/x, which can
throw an error if x=0.
* Index quals are more optimizable, because such operators are not
supposed to throw errors or have side effects, so we can evaluate them
before determining visibility.

I wouldn't describe one as "better" than the other, but I assume you
meant "more optimizable".

It's interesting that there's overlap in utility between Tomas's
current patch and Peter's work on optimizing SAOPs. But I don't see a
lot of tension there -- it seems like Tomas's patch will always be
useful for filters that might throw an error (or have other side
effects).

Is there any part of the design here that's preventing this patch from
moving forward? If not, what are the TODOs for the current patch, or is
it just waiting on more review?

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-08-17 23:31:37 Re: Normalization of utility queries in pg_stat_statements
Previous Message Michael Paquier 2023-08-17 23:19:14 Re: Fix an entry in wait_event_names.txt