Re: pgsql: Support partition pruning at execution time

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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