Re: BitmapHeapScan streaming read user and prelim refactoring
От | Melanie Plageman |
---|---|
Тема | Re: BitmapHeapScan streaming read user and prelim refactoring |
Дата | |
Msg-id | CAAKRu_bzhunY_Hha7i6vMRfQkzgmU5YPtgrrFZBw7aF7ysmrJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BitmapHeapScan streaming read user and prelim refactoring (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: BitmapHeapScan streaming read user and prelim refactoring
|
Список | pgsql-hackers |
On Wed, Feb 28, 2024 at 2:23 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > On 2/28/24 15:56, Tomas Vondra wrote: > >> ... > > > > Sure, I can do that. It'll take a couple hours to get the results, I'll > > share them when I have them. > > > > Here are the results with only patches 0001 - 0012 applied (i.e. without > the patch introducing the streaming read API, and the patch switching > the bitmap heap scan to use it). > > The changes in performance don't disappear entirely, but the scale is > certainly much smaller - both in the complete results for all runs, and > for the "optimal" runs that would actually pick bitmapscan. Hmm. I'm trying to think how my refactor could have had this impact. It seems like all the most notable regressions are with 4 parallel workers. What do the numeric column labels mean across the top (2,4,8,16...) -- are they related to "matches"? And if so, what does that mean? - Melanie
В списке pgsql-hackers по дате отправления: