From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Étienne BERSAC <etienne(dot)bersac(at)dalibo(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, jtc331(at)gmail(dot)com, rafaelthca(at)gmail(dot)com |
Subject: | Re: RFC: Logging plan of the running query |
Date: | 2024-02-12 00:00:00 |
Message-ID: | CACJufxHZ5sf1a6zuCmpH3NP6EnVE34py_Ou1jPF6pUhTOkEQOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 7, 2024 at 12:58 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> >
> > > */
> > > How bad this performance could be. Let's assume that a query is taking
> > > time and pg_log_query_plan() is invoked to examine the plan of this
> > > query. Is it possible that the looping over all the locks itself takes
> > > a lot of time delaying the query execution further?
> >
corner case test:
pgbench --initialize --partition-method=range --partitions=20000
Somehow my setup, the pg_bench didn't populate the data but there are
20000 partitions there.
(all my other settings are default)
some interesting things happened when a query touch so many partitions like:
select abalance, aid from public.pgbench_accounts,pg_sleep(4) where aid > 1;
in another session, if you immediate call SELECT pg_log_query_plan(9482);
then output be
`
LOG: backend with PID 9482 is not running a query or a subtransaction
is aborted
`
however if you delay a little bit of time (like 1 second), then
LOG will emit the plan with lots of text (not sure the plan is right).
I think the reason is that the `InitPlan` within
standard_ExecutorStart takes more time to finish
when your query touches a lot of partitions.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-02-12 00:10:45 | Re: GUC-ify walsender MAX_SEND_SIZE constant |
Previous Message | rs.trevk | 2024-02-11 23:12:02 | RE: Feature request support MS Entra ID Authentication from On-premises PostreSQL server |