From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Explain Analyze (Rollback off) Suggestion |
Date: | 2020-05-28 00:31:27 |
Message-ID: | 5119.1590625887@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think the only way to make the effects of an EXPLAIN ANALYZE
> statement be automatically rolled back would be to wrap the entire
> operation in a subtransaction. While we could certainly implement
> that, it might have its own share of surprises; for example, it would
> consume an XID, leading to faster wraparound vacuums if you do it
> frequently.
Right, but it's just automating something that people now do by hand
(ie manually wrap the EXPLAIN in BEGIN/ROLLBACK) when that's what they
need. I think the idea of having an option to do it for you isn't bad.
I'm strongly against changing the very-longstanding default behavior of
EXPLAIN ANALYZE, though; the villagers at your doorstep will not be
bringing flowers. So this new option has to *not* default to on.
As far as the general topic of the thread goes, I like the idea of
controlling EXPLAIN options on the client side way better than inventing
statement-behavior-altering GUCs. We learned our lesson about that a
decade or two back; only those who don't remember propose new ones.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Gilman | 2020-05-28 00:33:47 | Re: Warn when parallel restoring a custom dump without data offsets |
Previous Message | Kyotaro Horiguchi | 2020-05-28 00:11:14 | Re: tablespace_map code cleanup |