Re: [HACKERS] Burst in WAL size when UUID is used as PK whilefull_page_writes are enabled

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: [HACKERS] Burst in WAL size when UUID is used as PK whilefull_page_writes are enabled
Дата
Msg-id 19cf10a7-4741-0255-a656-0fe5fb9e5cd8@2ndquadrant.com
обсуждение исходный текст
Ответ на [HACKERS] Burst in WAL size when UUID is used as PK while full_page_writes areenabled  (sanyam jain <sanyamjain22@live.in>)
Список pgsql-hackers

On 10/27/2017 07:56 AM, sanyam jain wrote:
> Hi,
> 
> I was reading the
> blog https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes .
> 

For the record, I assume you're referring to this part:
   With BIGSERIAL new values are sequential, and so get inserted to the   same leaf pages in the btree index. As only
thefirst modification   to a page triggers the full-page write, only a tiny fraction of the   WAL records are FPIs.
WithUUID it’s completely different case, of   couse – the values are not sequential at all, in fact each insert is
likelyto touch completely new leaf index leaf page (assuming the   index is large enough).
 

> My queries:
> 
> How randomness of UUID will likely to create new leaf page in btree index?
> In my understanding as the size of UUID is 128 bits i.e. twice of
> BIGSERIAL , more number of pages will be required to store the same
> number of rows and hence there can be increase in WAL size due to FPW .
> When compared the index size in local setup UUID index is ~2x greater in
> size.
> 

Perhaps this is just a poor choice of words on my side, but I wasn't
suggesting new leaf pages will be created but merely that the inserts
will touch a different (possibly existing) leaf page. That's a direct
consequence of the inherent UUID randomness.

regards

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [HACKERS] WIP: BRIN bloom indexes