RE: Is this a problem in GenericXLogFinish()?

Поиск
Список
Период
Сортировка
От Hayato Kuroda (Fujitsu)
Тема RE: Is this a problem in GenericXLogFinish()?
Дата
Msg-id TYAPR01MB58663DB52ED18495A5AD1338F5AEA@TYAPR01MB5866.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: Is this a problem in GenericXLogFinish()?  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Ответы Re: Is this a problem in GenericXLogFinish()?  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Dear hackers,

> Next we should add some test codes. I will continue considering but please post
> anything
> If you have idea.

And I did, PSA the patch. This patch adds two parts in hash_index.sql.

In the first part, the primary bucket page is filled by live tuples and some overflow
pages are by dead ones. This leads removal of overflow pages without moving tuples.
HEAD will crash if this were executed, which is already reported on hackers.

The second one tests a case (ntups == 0 && is_prim_bucket_same_wrt == false &&
is_prev_bucket_same_wrt == true), which is never done before.



Also, I measured the execution time of before/after patching. Below is a madian
for 9 measurements.

BEFORE -> AFTER
647 ms -> 710 ms

This means that the execution time increased -10%, it will not affect so much.

How do you think?

Best Regards,
Hayato Kuroda
FUJITSU LIMITED



Вложения

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

Предыдущее
От: torikoshia
Дата:
Сообщение: Re: Add new option 'all' to pg_stat_reset_shared()
Следующее
От: Andres Freund
Дата:
Сообщение: AdvanceXLInsertBuffers() vs wal_sync_method=open_datasync