From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, jian he <jian(dot)universality(at)gmail(dot)com> |
Subject: | Re: question about executor hooks |
Date: | 2025-01-14 15:59:52 |
Message-ID: | CAA5RZ0vUUcA4h6tVwwHLsy46Fioy-DMBr1AOHO9LGKNHNH4MjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I recommend you to review the documentation in
backend/executor/README. It explains in good detail how
the executor works. Specifically the section "Query Processing Control Flow"
explains what each of the hooks you reference are responsible for.
Also, be aware that there are operations, called utility statements,
that may not go through the executor; i.e. CREATE TABLE t (id int),
will go through ProcessUtility ( also has a hook ) only as it's a utility
statement and not a plannable statement.
As mentioned above, pg_stat_statements is a good reference extension
that implements these hooks for query level executions statistics.
> Moreover, installing an hook is cluster-wide, right? Is there a way to
> limit an hook only for connections related to a single database
> (without taking into account FDW and friends)?
It depends on the hook. pg_stat_statements for example loads the
hooks at startup time, but the extension itself implements a GUC
that allows a user to skip doing any work inside these hooks.
Regards,
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo NAGATA | 2025-01-14 16:21:41 | Re: psql: Add leakproof field to \dAo+ meta-command results |
Previous Message | Jakob Egger | 2025-01-14 15:51:05 | Re: Use Python "Limited API" in PL/Python |