Re: Use of additional index columns in rows filtering

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Use of additional index columns in rows filtering
Дата
Msg-id CAH2-WzkWXBYpSsi60ZzhKM5vZsHwFpWE_zj=PupPoXFN1nPoCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Use of additional index columns in rows filtering  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: Use of additional index columns in rows filtering
Список pgsql-hackers
On Thu, Aug 3, 2023 at 4:20 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> Which is just the 7 buffers ...
>
> Did I do something wrong?

I think that it might have something to do with your autovacuum
settings. Note that the plan that you've shown for the master branch
isn't the same one that appears in
src/test/regress/expected/create_index.out for the master branch --
that plan (the BitmapOr plan) was my baseline case for master.

That said, I am a little surprised that you could ever get the plan
that you showed for master (without somehow unnaturally forcing it).
It's almost the same plan that your patch gets, but much worse. Your
patch can use an index filter, but master uses a table filter instead.

While the plan used by the patch is risky in the way that I described,
the plan you saw for master is just horrible. I mean, it's not even
risky -- it seems almost certain to lose. Whereas at least the plan
from the patch really is cheaper than the BitmapOr plan (the master
branch plan from create_index.out) on average.

--
Peter Geoghegan



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

Предыдущее
От: "Tristan Partin"
Дата:
Сообщение: Re: Improve const use in zlib-using code
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: [RFC] Clang plugin for catching suspicious typedef casting