From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | David Fetter <david(at)fetter(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New EXPLAIN option: ALL |
Date: | 2019-05-21 18:33:50 |
Message-ID: | 11848.1558463630@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-05-21 19:38:57 +0200, David Fetter wrote:
>> On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
>>> Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
>> Would this be worth back-patching? I ask because adding it will cause
>> fairly large (if mechanical) churn in the regression tests.
> This is obviously a no. But I don't even know what large mechanical
> churn you're talking about? There's not that many files with EXPLAIN
> (ANALYZE) in the tests - we didn't have any until recently, when we
> added SUMMARY OFF, to turn off non-deterministic details (f9b1a0dd4).
partition_prune.sql has got kind of a lot of them though :-(
src/test/regress/sql/tidscan.sql:3
src/test/regress/sql/partition_prune.sql:46
src/test/regress/sql/select_parallel.sql:3
src/test/regress/sql/select.sql:1
src/test/regress/sql/subselect.sql:1
Still, if we're adding BUFFERS OFF in the same places we have
SUMMARY OFF, I agree that it won't create much new hazard for
back-patching --- all those places already have a limit on
how far they can be back-patched.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-05-21 18:48:27 | Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL |
Previous Message | Tom Lane | 2019-05-21 18:27:33 | Re: Re: Re: Refresh Publication takes hours and doesn´t finish |