Re: pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case |
| Дата | |
| Msg-id | 2443.1231781623@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case (Gregory Stark <stark@enterprisedb.com>) |
| Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes:
> tgl@postgresql.org (Tom Lane) writes:
>> Tweak order of operations in BitmapHeapNext() to avoid the case of prefetching
>> the same page we are nanoseconds away from reading for real. There should be
>> something left to do on the current page before we consider issuing a prefetch.
> Doesn't this break things if, say, there's precisely one tuple on every page?
No. It'd only break things if there were zero tuples on each page, but
that's not possible (else the page wouldn't be in the index output to
begin with).
There is a bit of oddness in how fast the target ramps up, because of
the target++ in the "Continuing in previously obtained page" path.
I wasn't too happy with that target++ to begin with, but am not sure
what's a saner thing to do there.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера