What capability does this add to VEF?
A way for extensions to observe statements as they complete — receiving query text, execution time, rows examined/sent, error state, current schema, and connection ID once per finished statement, regardless of whether the statement called any extension function.
Which epics depend on this hook?
None filed yet. The motivating scenario is a query telemetry exporter: install an extension, configure a destination (e.g. ClickHouse), get per-query analytics automatically with no application code changes. Reference implementation in PostgreSQL: pg_stat_ch, which uses ExecutorEnd_hook for exactly this.
Additional context
The natural delivery model may be out-of-process rather than an in-process VEF callback: the server writes events to a Unix domain socket or named pipe, and a companion process consumes them. That companion can be written in any language and restarted independently of the server. If that's the direction, this capability is more [Server] than [VEF Hook] — flagging it here so the right label gets applied.
An in-process variant — events delivered to a thread_worker via POLL_FD — would also be useful for extensions that need tighter integration with other VEF capabilities. The two aren't mutually exclusive.
Current workaround: poll performance_schema.events_statements_history_long from a thread_worker. Silently drops events that scroll out of the history ring at high throughput.
What capability does this add to VEF?
A way for extensions to observe statements as they complete — receiving query text, execution time, rows examined/sent, error state, current schema, and connection ID once per finished statement, regardless of whether the statement called any extension function.
Which epics depend on this hook?
None filed yet. The motivating scenario is a query telemetry exporter: install an extension, configure a destination (e.g. ClickHouse), get per-query analytics automatically with no application code changes. Reference implementation in PostgreSQL: pg_stat_ch, which uses
ExecutorEnd_hookfor exactly this.Additional context
The natural delivery model may be out-of-process rather than an in-process VEF callback: the server writes events to a Unix domain socket or named pipe, and a companion process consumes them. That companion can be written in any language and restarted independently of the server. If that's the direction, this capability is more [Server] than [VEF Hook] — flagging it here so the right label gets applied.
An in-process variant — events delivered to a
thread_workerviaPOLL_FD— would also be useful for extensions that need tighter integration with other VEF capabilities. The two aren't mutually exclusive.Current workaround: poll
performance_schema.events_statements_history_longfrom athread_worker. Silently drops events that scroll out of the history ring at high throughput.