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 по дате отправления: