Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, May 20, 2019 at 4:46 PM Tom Lane <tgl@sss.pgh.pa.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
