| From: | James Coleman <jtc331(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Étienne BERSAC <etienne(dot)bersac(at)dalibo(dot)com>, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com, rafaelthca(at)gmail(dot)com, jian(dot)universality(at)gmail(dot)com |
| Subject: | Re: RFC: Logging plan of the running query |
| Date: | 2024-03-02 15:46:36 |
| Message-ID: | CAAaqYe-7QiAufDmfExAOZKcZTOR5dkuVSMxXRPEooaCaPfFqtA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 28, 2024 at 1:18 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Mon, Feb 26, 2024 at 5:31 PM torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> wrote:
> > It would be nice if there was a place accessed once every few seconds or
> > so..
>
> I think this comment earlier from Andres deserves close attention:
>
> # If we went with something like tht approach, I think we'd have to do something
> # like redirecting node->ExecProcNode to a wrapper, presumably from within a
> # CFI. That wrapper could then implement the explain support, without slowing
> # down the normal execution path.
>
> If this is correctly implemented, the overhead in the case where the
> feature isn't used should be essentially zero, I believe.
If I can rephrase this idea: it's basically "delay this interrupt
until inline to the next ExecProcNode execution".
That seems pretty promising to me as well.
Regards,
James Coleman
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2024-03-02 17:34:10 | Re: Commitfest Manager for March |
| Previous Message | Tomas Vondra | 2024-03-02 15:05:07 | Re: BitmapHeapScan streaming read user and prelim refactoring |