Re: Parallel Append subplan order instability on aye-aye

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Append subplan order instability on aye-aye
Date: 2019-05-21 00:07:22
Message-ID: 21395.1558397242@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Mon, May 20, 2019 at 4:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Note that in the discussion that led up to 624e440a, we never did
>> think that we'd completely explained the original irreproducible
>> failure.

> I think it might be dependent on incidental vacuum/analyze activity
> having updated reltuples.

The problem is to explain where said activity came from. a_star and
its children are too small to attract autovacuum's attention. They
get created/filled in create_table.sql/create_misc.sql, and then they
get explicitly vacuum'd by sanity_check.sql, and then after that
things are 100% stable. Or should be.

There are some incidental ALTER TABLEs on them in misc.sql and
select_parallel.sql, but those shouldn't have any interesting
effects on the rowcount estimates ... and even if they do,
why would such effects not be reproducible?

So I'm not excited about sticking in an extra vacuum or analyze
without actually understanding why the irreproducible behavior
happens. It's not exactly implausible that that'd make it
worse not better.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-05-21 00:33:54 Re: Caveats from reloption toast_tuple_target
Previous Message David Rowley 2019-05-21 00:04:50 Re: PG 12 draft release notes