| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(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 14:52:47 |
| Message-ID: | 6667.1590677567@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> The ANALYZE option should not be part of the GUC setup.
Yeah. While I'm generally not in favor of putting GUCs into the mix
here, the only one that seriously scares me is a GUC that would affect
whether the EXPLAIN'd query executes or not. A GUC that causes buffer
counts to be reported/not-reported is not going to result in data
destruction when someone forgets that it's on.
(BTW, adding an option for auto-rollback wouldn't change my opinion
about that. Not all side-effects of a query can be rolled back. Thus,
if there is an auto-rollback option, it mustn't be GUC-adjustable
either.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2020-05-28 14:56:22 | Re: Explain Analyze (Rollback off) Suggestion |
| Previous Message | Tom Lane | 2020-05-28 14:44:30 | Re: Resolving the python 2 -> python 3 mess |