| From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> | 
|---|---|
| To: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> | 
| Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: RFC: Logging plan of the running query | 
| Date: | 2021-05-12 14:40:46 | 
| Message-ID: | 20210512144046.tjyg7wxcndd2dmmu@nol | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Wed, May 12, 2021 at 08:24:04PM +0900, torikoshia wrote:
> Hi,
> 
> During the discussion about memory contexts dumping[1], there
> was a comment that exposing not only memory contexts but also
> query plans and untruncated query string would be useful.
> 
> I also feel that it would be nice when thinking about situations
> such as troubleshooting a long-running query on production
> environments where we cannot use debuggers.
> 
> At that point of the above comment, I was considering exposing
> such information on the shared memory.
> However, since memory contexts are now exposed on the log by
> pg_log_backend_memory_contexts(PID), I'm thinking about
> defining a function that logs the plan of a running query and
> untruncated query string on the specified PID in the same way
> as below.
> 
>   postgres=# SELECT * FROM pg_log_current_plan(2155192);
>    pg_log_current_plan
>   ---------------------
>    t
>   (1 row)
> 
>   $ tail -f data/log/postgresql-2021-05-12.log
> 
>   2021-05-12 17:37:19.481 JST [2155192] LOG:  logging the plan of running
> query on PID 2155192
>           Query Text: SELECT a.filler FROM pgbench_accounts a JOIN
> pgbench_accounts b ON a.aid = b.aid;
>           Merge Join  (cost=0.85..83357.85 rows=1000000 width=85)
>             Merge Cond: (a.aid = b.aid)
>             ->  Index Scan using pgbench_accounts_pkey on pgbench_accounts a
> (cost=0.42..42377.43 rows=1000000 width=89)
>             ->  Index Only Scan using pgbench_accounts_pkey on
> pgbench_accounts b  (cost=0.42..25980.42 rows=1000000 width=4)
I didn't read the POC patch yet, but +1 for having that feature.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2021-05-12 14:45:06 | Re: OOM in spgist insert | 
| Previous Message | Tom Lane | 2021-05-12 13:50:10 | Re: Do we need to rethink how to parallelize regression tests to speedup CLOBBER_CACHE_ALWAYS? |