From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Force testing of query jumbling code in TAP tests |
Date: | 2023-02-14 18:11:21 |
Message-ID: | 20230214181121.eymoiaccog4sxu2e@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-02-14 16:04:16 +0900, Michael Paquier wrote:
> On Mon, Feb 13, 2023 at 09:45:12AM -0800, Andres Freund wrote:
> > Shouldn't there at least be some basic verification of pg_stat_statements
> > output being sane after running the test? Even if that's perhaps just actually
> > printing the statements.
>
> There is a total of 20k entries in pg_stat_statements if the max is
> high enough to store everything. Only dumping the first 100
> characters of each query generates at least 1MB worth of logs, which
> would bloat a lot of the buildfarm in each run. So I would not do
> that. One thing may be perhaps to show a count of the queries in five
> categories: select, insert, delete, update and the rest?
I didn't mean printing in the sense of outputting the statements to the tap
log. Maybe creating a temp table or such for all the queries. And yes, then
doing some top-level analysis on it like you describe sounds like a good idea.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-14 19:08:12 | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
Previous Message | Andres Freund | 2023-02-14 17:59:57 | Re: Move defaults toward ICU in 16? |