David Rowley <dgrowle...@gmail.com> writes: > I see 0c882e52a did change the number of statistics targets on that > table. The first failure was on the commit directly after that one. > I'm not sure what instability Tom meant when he wrote "-- results > below depend on having quite accurate stats for atest12".
See [1], particularly the para about "When I went to test 0002". At least one of those test cases fails if the planner estimates more than one row being selected by the user-defined operator, and since the table has 10K rows, that means we need 1/10000 selectivity precision. > It does seem plausible, given how slow prion is that autovacuum might > be trigger after the manual vacuum somehow and building stats with > just 1k buckets instead of 10k. Hmm ... that's a plausible theory, perhaps. I forget: does autovac recheck, after acquiring the requisite table lock, whether the table still needs to be processed? > 0936d1b6 made some changes to disable > autovacuum because it was sometimes coming in and messing with the > statistics, maybe we need to do the same here, or at least do > something less temporary than changing default_statistics_target. Yeah, setting that as a table parameter seems like a better idea than setting default_statistics_target. regards, tom lane