Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Questions: > 1. Do we want to back-patch this to 10? I suppose (without checking) > that EXPLAIN ANALYZE is already reporting bogus numbers for parallel > index-only scans, so I think we should do that.
You can't back-patch a change in struct Instrumentation; that'd be a ABI break. Maybe there are no third parties directly touching that struct, but I wouldn't bet on it. > 2. Do we want to revert Andrew's test stabilization patch? If I > understand correctly, the problem is the inverse of what was diagnosed: > "any running transaction at the time of the test could prevent pages > from being set as all-visible". That's correct, but the test doesn't > depend on pages being all-visible -- quite the contrary, it depends on > the pages NOT being all-visible (which is why the HeapFetches counts are > all non-zero). Since the pages contain very few tuples, autovacuum > should never process the tables anyway. I did not especially like the original test output, because even without the bug at hand, it seemed to me the number of heap fetches might vary depending on BLCKSZ. Given that the point of the test is just to check partition pruning, seems like IOS vs regular indexscan isn't a critical difference. I'd keep Andrew's change but fix the comment. regards, tom lane