| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
| Cc: | Andrei Lepikhov <lepihov(at)gmail(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-29 16:30:47 |
| Message-ID: | CA+Tgmoa4mN8f31ye8S6C_fWgqwucdHjCoa7MBp0_PuNLzLPj2Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 29, 2026 at 12:23 AM torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> wrote:
> I think this behavior is specific to pg_log_query_plan(), so I am
> starting to wonder whether something should be mentioned in the
> documentation.
Yeah, that's fair. In that case, the delay could be longer than what
people might expect, so it could be worth calling out for that reason.
It still feels optional to me, but I'm fine if you want to mention it.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-06-29 16:54:44 | Re: Handle concurrent drop when doing whole database vacuum |
| Previous Message | Bharath Rupireddy | 2026-06-29 16:22:24 | Re: Handle concurrent drop when doing whole database vacuum |