Re: Parallel Append subplan order instability on aye-aye
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-05-21T00:07:22Z
Lists: pgsql-hackers
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
Commits
-
ANALYZE a_star and its children to avoid plan instability in tests.
- e40f3c747203 12.0 landed
- b9bffa004a99 13.0 landed
-
Finish reverting "Insert temporary debugging output in regression tests."
- d9cacca2d139 13.0 landed
-
Partially revert "Insert temporary debugging output in regression tests."
- b43f7c117e66 13.0 landed
-
Insert temporary debugging output in regression tests.
- f03a9ca4366d 12.0 landed
-
Improve the heuristic for ordering child paths of a parallel append.
- 624e440a4744 11.0 cited