Re: Generating code for query jumbling through gen_node_support.pl

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Generating code for query jumbling through gen_node_support.pl
Дата
Msg-id 20230208070103.43fbdg6jj23savh4@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Generating code for query jumbling through gen_node_support.pl  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Generating code for query jumbling through gen_node_support.pl  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hi,

On 2023-02-08 15:47:51 +0900, Michael Paquier wrote:
> This one was intentional to let extensions play with jumbling of such
> nodes, but perhaps you are right that it makes little sense at this
> stage.  If there is an ask for it later, though..  Using
> shared_preload_libraries = pg_stat_statements and compute_query_id =
> regress shows that numbers go up to 60% for funcs.c and 30% for
> switch.c.  Removing nodes like as of the attached brings these numbers
> respectively up to 94.5% and 93.5% for a check.  With a check-world, I
> measure respectively 96.7% and 96.1% because there is more coverage
> for extensions, ALTER SYSTEM and database commands, roughly.

Given that we already pay the price of multiple regress runs, and that
jumbling is now really a core feature, perhaps we should enable
pg_stat_statements in pg_upgrade or 027_stream_regress.pl? I'd hope it
wouldn't add a meaningful amount of time?  A tiny bit of verification at the
end should also be ok.

Both pg_upgrade and 027_stream_regress.pl have some advantages. The former
would test pg_upgrade interactions with shared_preload_libraries, the latter
could do some basic checks of pg_stat_statements on a standby.

Greetings,

Andres Freund



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Generating code for query jumbling through gen_node_support.pl
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)