David Rowley <dgrowleyml@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