Re: RFC: Logging plan of the running query

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: torikoshia <torikoshia@oss.nttdata.com>

Cc: Julien Rouhaud <rjuju123@gmail.com>, James Coleman <jtc331@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org, Étienne BERSAC <etienne.bersac@dalibo.com>, ashutosh.bapat.oss@gmail.com, rafaelthca@gmail.com, jian.universality@gmail.com

Date: 2024-02-28T06:18:32Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

ecpg: Catch zero-length Unicode identifiers correctly
- a18b6d2dc288 15.0 cited
Improve warning message in pg_signal_backend()
- 7fa945b857cc 15.0 cited
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 cited

On Mon, Feb 26, 2024 at 5:31 PM torikoshia <torikoshia@oss.nttdata.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.

-- 
Robert Haas
EDB: http://www.enterprisedb.com