Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Дата
Msg-id ZCE5RC78LaudfeJp@paquier.xyz
обсуждение исходный текст
Ответ на Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Andres Freund <andres@anarazel.de>)
Ответы Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Список pgsql-hackers
On Fri, Mar 24, 2023 at 08:00:44PM -0700, Andres Freund wrote:
> I don't understand what we're optimizing for here. These functions are very
> very very far from being a hot path. The xact functions are barely ever
> used. Compared to the cost of query evaluation the cost of iterating throught
> he subxacts is neglegible.

I was wondering about that, and I see why I'm wrong.  I have quickly
gone up to 10k subtransactions, and while I was seeing what looks like
difference of 8~10% in runtime when looking at
pg_stat_xact_all_tables, the overval runtime was still close enough
(5.8ms vs 6.4ms).  At this scale, possible that it was some noise,
these seemed repeatable still not to worry about.

Anyway, I was looking at this patch, and I still feel that it is a bit
incorrect to have the copy of PgStat_TableStatus returned by
find_tabstat_entry() to point to the same list of subtransaction data
as the pending entry found, while the counters are incremented.  This
could lead to mistakes if the copy from find_tabstat_entry() is used
in an unexpected way in the future.  The current callers are OK, but
this does not give me a warm feeling :/
--
Michael

Вложения

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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: refactoring relation extension and BufferAlloc(), faster COPY
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Support logical replication of DDLs