Re: optimizing vacuum truncation scans

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: optimizing vacuum truncation scans
Дата
Msg-id CANP8+jKJ8DQOOvRBXVuKyXYs7-3jaGzoj53pFqALq15SZGKYKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: optimizing vacuum truncation scans  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On 3 August 2015 at 17:18, Jeff Janes <jeff.janes@gmail.com> wrote:
 
That does still leave the prefetch technique, so all is not lost.

Can we see a patch with just prefetch, probably with a simple choice of stride? Thanks.

I probably won't get back to it this commit fest, so it can be set to returned with feedback.  But if anyone has good ideas for how to set the stride (or detect that it is on SSD and so is pointless to try) I'd love to hear about them anytime.

I've Returned With Feedback, as you suggest.

Given your earlier numbers, I'd just pick a constant value of 128, to keep it simple. That balances out the various factors of small/large tables and the uncertainty that we will be able to truncate the whole chunk of blocks. I'd like to see tests on SSD before commit, but I hope and expect the slightly negative results with SSD won't be substantiated on larger tests.

Kept simple, its a patch with a clear win in a restricted use case and I would be happy to commit that sometime in the future.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Macro nesting hell
Следующее
От: Andres Freund
Дата:
Сообщение: Warnings around booleans