Re: Use of additional index columns in rows filtering
От | Jeff Davis |
---|---|
Тема | Re: Use of additional index columns in rows filtering |
Дата | |
Msg-id | 1368005e1e475e40cf0420708c57b00cac59a181.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Use of additional index columns in rows filtering (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Use of additional index columns in rows filtering
|
Список | 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
В списке pgsql-hackers по дате отправления: