Minor optimizations in lazy_scan_heap

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Minor optimizations in lazy_scan_heap
Дата
Msg-id CABOikdP05GmaV=3vA7isJA7KO=iWCXGaBSnq7J+Hgqwq9WkFkg@mail.gmail.com
обсуждение исходный текст
Ответы Re: Minor optimizations in lazy_scan_heap
Список pgsql-hackers
I was looking at the code in lazy_scan_heap() and I realized there are couple of low-hanging optimizations that we can
dothere.<br /><br />1. The for-loop walks through each block of the relation. But if scan_all is set to false, which
wouldbe the case most often, we can jump over to the next not-all-visible block directly (after considering the
SKIP_PAGES_THRESHOLDetc). I understand that the cost of looping with no-op may not be considerable, but it looks
unnecessary.And it can matter when there are thousands and millions of consecutive all-visible blocks in a large
table.<br/><br />2. We also do a visibilitymap_test() for each block. I think it will be more prudent to have a
visibilitymapAPI, say visibilitymap_test_range(), which can take a range of blocks and return the first not-all-visible
blockfrom the range. Internally, the function can then test several blocks at a time. We can still do this without
holdinga lock on the VM buffer because when scan_all is false, we don't care much about the correctness of the
visibilitycheck anyway. Also, this function can later be optimized if we start saving some summary information about
visibilitymaps, in which case we can more efficiently find first not-all-visible block.<br /><br />3. I also thought
thatthe call to vacuum_delay_point() for every visibility check is not required and a simple CHECK_FOR_INTERRUPTS would
begood enough. Later I realized that may be we need that because visibility map check can do an IO for the VM page. But
ifwe do 2, then we can at least limit calling vacuum_delay_point() once for every VM page, instead of one per bit. I
concedethat the cost of calling vacuum_delay_point() may not be too high, but it again looks unnecessary and can be
takencare by a slight re-factoring of the code.<br /><br />Comments ? Anyone thinks any/all of above is useful ?<br
/><br/>Thanks,<br />Pavan<br clear="all" /><br />-- <br />Pavan Deolasee<br /><a
href="http://www.linkedin.com/in/pavandeolasee"target="_blank">http://www.linkedin.com/in/pavandeolasee</a><br /> 

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

Предыдущее
От: "Etsuro Fujita"
Дата:
Сообщение: Re: Patch for removng unused targets
Следующее
От: "Erik Rijkers"
Дата:
Сообщение: Re: WIP: index support for regexp search