Re: Is this a problem in GenericXLogFinish()?

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: Is this a problem in GenericXLogFinish()?
Дата
Msg-id 9aa385d8-fe75-c35b-cf91-31bb3647d977@gmail.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
Hello Kuroda-san,

30.11.2023 10:28, Hayato Kuroda (Fujitsu) wrote:
> Again, good catch. Here is my analysis and fix patch.
> I think it is sufficient to add an initialization for writebuf.

I agree with the change. It aligns hash_xlog_squeeze_page() with
hash_xlog_move_page_contents() in regard to initialization of writebuf.
Interestingly enough, the discrepancy exists since these functions
appeared with c11453ce0, and I can't see what justified adding the
initialization inside hash_xlog_move_page_contents() only.
So I think that if this doesn't affect performance, having aligned coding
(writebuf initialized in both functions) is better.

> I want to add a test case for it as well. I've tested on my env and found that proposed
> tuples seems sufficient.
> (We must fill the primary bucket, so initial 500 is needed. Also, we must add
> many dead pages to lead squeeze operation. Final page seems OK to smaller value.)
>
> I compared the execution time before/after patching, and they are not so different
> (1077 ms -> 1125 ms).
>
> How do you think?

I can confirm that the test case proposed demonstrates what is expected
and the duration increase is tolerable, as to me.

Best regards,
Alexander



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

Предыдущее
От: Alena Rybakina
Дата:
Сообщение: Re: POC, WIP: OR-clause support for indexes
Следующее
От: Gabriele Bartolini
Дата:
Сообщение: Re: Extend pgbench partitioning to pgbench_history