Re: [HACKERS] increasing the default WAL segment size

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] increasing the default WAL segment size
Дата
Msg-id CA+TgmoZTgnL25o68uPBTS6BD37ojD-1y-N88PkP57FzKqwcmmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: increasing the default WAL segment size  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] increasing the default WAL segment size  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Dec 20, 2016 at 3:28 AM, Andres Freund <andres@anarazel.de> wrote:
> I do think this has the potential for negative performance
> implications. Consider code like
>                         /* skip over the page header */
>                         if (CurrPos % XLogSegSize == 0)
>                         {
>                                 CurrPos += SizeOfXLogLongPHD;
>                                 currpos += SizeOfXLogLongPHD;
>                         }
>                         else
> right now that's doable in an efficient manner, because XLogSegSize is
> constant. If it's a variable and the compiler doesn't even know it's a
> power-of-two, it'll have to do a full "div" - and that's quite easily
> noticeable in a lot of cases.
>
> Now it could entirely be that the costs of this will be swamped by
> everything else, but I'd not want to rely on it.

We could use the GUC assign hook to compute a mask and a shift, so
that this could be written as (CurrPos & mask_variable) == 0.  That
would avoid the division instruction, though not the memory access.  I
hope this is all in the noise, though.  I know this is code is hot but
I think it'll be hard to construct a test case where the bottleneck is
anything other than the speed at which the disk can absorb bytes.  I
suppose we could set fsync=off and put the whole cluster on a RAMDISK
to avoid those bottlenecks, but of course no real storage system
behaves like that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] too low cost of Bitmap index scan
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Time to drop old-style (V0) functions?