| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Rafael Thofehrn Castro <rafaelthca(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal: Progressive explain |
| Date: | 2025-03-26 13:44:43 |
| Message-ID: | CA+TgmoZ51Hc7o_vFo8rbPqkLpSVzH6i=ccPrt2mHBPyk=zMxwQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 25, 2025 at 8:52 PM Rafael Thofehrn Castro
<rafaelthca(at)gmail(dot)com> wrote:
> This first version of the progressive explain feature was designed to only keep
> track of initial query called by the backend, ignoring all subquery calls. So
> I believe we don't need to worry about having to add custom logic in
> AbortSubTransaction(). In case query errors out AbortTransaction() will be called
> and everything related to progressive explains will be cleaned.
Suppose:
BEGIN;
SELECT 1;
SAVEPOINT bob;
progressively explain something that aborts
I think in this case we will call AbortSubTransaction(), not AbortTransaction().
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-03-26 13:52:09 | Re: vacuum_truncate configuration parameter and isset_offset |
| Previous Message | Rafael Thofehrn Castro | 2025-03-26 13:10:39 | Re: Proposal: Progressive explain |