Re: RFC: Logging plan of the running query
От | jian he |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | CACJufxHZ5sf1a6zuCmpH3NP6EnVE34py_Ou1jPF6pUhTOkEQOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: Logging plan of the running query (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: RFC: Logging plan of the running query
|
Список | pgsql-hackers |
On Wed, Feb 7, 2024 at 12:58 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.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.
В списке pgsql-hackers по дате отправления: