| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Atsushi Torikoshi <torikoshia(dot)tech(at)gmail(dot)com>, samimseih(at)gmail(dot)com, destrex271(at)gmail(dot)com |
| Subject: | Re: RFC: Logging plan of the running query |
| Date: | 2026-06-26 12:50:56 |
| Message-ID: | CA+TgmoYS7BzX3Zu+A-ZGd026q5nyC5cctjiVeZNwj1eYSqoOaQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 25, 2026 at 6:33 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> Ok, so just mention this behaviour in the documentation - let people know that
> they should potentially wait for a minute or two more to see the EXPLAIN.
> Real-life with huge queries and big machines provide us with examples where a
> backend might delay a response to a signal for quite a substantial time.
>
> Sometimes nothing happens after such an async operation, and we need to identify
> the problem: has the backend stalled, is the ‘logging plan’ algorithm
> ineffective, or is something else happening?
I don't think we document this in other, similar cases. Many things
can be delayed if the machine is overloaded, but unless I am missing
something, having to wait over a minute for this to work would be
*extremely* unusual and only happen in case of a machine that is
absolutely being crushed by the load. And in that case everything else
will be slow, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jehan-Guillaume de Rorthais | 2026-06-26 12:55:24 | Re: Possible Visibility Map corruption in supported branches? |
| Previous Message | Ashutosh Bapat | 2026-06-26 12:41:50 | Re: [PATCH] Add hook for plugins to acquire sample rows during ANALYZE |