Re: pg_stat_statements: more test coverage

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pg_stat_statements: more test coverage
Дата
Msg-id 3ec31fed-044f-4dcf-98be-3b1692a00f60@eisentraut.org
обсуждение исходный текст
Ответ на Re: pg_stat_statements: more test coverage  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: pg_stat_statements: more test coverage  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On 27.12.23 09:08, Julien Rouhaud wrote:
> Hi,
> 
> On Tue, Dec 26, 2023 at 10:03 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> On 24.12.23 03:03, Michael Paquier wrote:
>>> - Use a DO block of a PL function, say with something like that to
>>> ensure an amount of N queries?  Say with something like that after
>>> tweaking pg_stat_statements.track:
>>> CREATE OR REPLACE FUNCTION create_tables(num_tables int)
>>>     RETURNS VOID AS
>>>     $func$
>>>     BEGIN
>>>     FOR i IN 1..num_tables LOOP
>>>       EXECUTE format('
>>>         CREATE TABLE IF NOT EXISTS %I (id int)', 't_' || i);
>>>     END LOOP;
>>> END
>>> $func$ LANGUAGE plpgsql;
>>
>> I tried it like this first, but this doesn't register as separately
>> executed commands for pg_stat_statements.
> 
> I was a bit surprised by that so I checked locally.  It does work as
> expected provided that you set pg_stat_statements.track to all:

Ok, here is an updated patch set that does it that way.

I have committed the patches 0002 and 0003 from the previous patch set 
already.

I have also enhanced the TAP test a bit to check the actual content of 
the output across restarts.

I'm not too hung up on the 0001 patch if others don't like that approach.
Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Add support for __attribute__((returns_nonnull))
Следующее
От: Robins Tharakan
Дата:
Сообщение: Re: pg_upgrade failing for 200+ million Large Objects