From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu> |
Subject: | Re: On-demand running query plans using auto_explain and signals |
Date: | 2015-09-09 08:46:52 |
Message-ID: | CAFj8pRAtxwTNNS+xPdSLt60-AgcrR1_3MWxsMYdEaDUeVUp=qA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Two notices:
>
> 1. The communication mechanism can be used more wide, than only for this
> purpose. We can introduce a SendInfoHook - and it can be used for any
> customer probes - memory, cpu, ...
>
Not sure if for CPU you can get any more insight than an external tool like
top(1) will provide. For the memory, it might be indeed useful in some way
(memory context inspection?)
CPU is probably nonsense - sorry - but there are more other possibilities,
how to use it - simple checking some internal states of extensions without
log processing or without gdb, etc
>
> So there's certainly a space for generalization. Rename it as
> pg_backend_info()?
>
It is good name, so why not?
>
> 2. With your support for explain of nested queries we have all what we
>> need for integration auto_explain to core.
>>
>
> Well, I don't quite see how that follows. What I'm really after is
> bringing instrumentation support to this, so that not only plan could be
> extracted, but also the rows/loops/times accumulated thus far during the
> query run.
>
It is possible, but not necessary step - but it is premature question in
this moment
Regards
Pavel
>
> --
> Alex
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2015-09-09 09:01:35 | Re: checkpointer continuous flushing |
Previous Message | Fabien COELHO | 2015-09-09 08:35:53 | Re: pgbench progress with timestamp |