Re: Parallel Append subplan order instability on aye-aye

On Wed, 17 Jul 2019 at 07:23, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2019-07-15 21:12:32 -0400, Tom Lane wrote:
> > But I bet that these tables forming
> > an inheritance hierarchy (with multiple inheritance even) does
> > have something to do with it somehow, because if this were a
> > generic VACUUM bug surely we'd be seeing it elsewhere.
>
> It's possible that it's hidden in other cases, because of
>
> void
> table_block_relation_estimate_size(Relation rel, int32 *attr_widths,
> BlockNumber *pages, double *tuples,
> double *allvisfrac,
> Size overhead_bytes_per_tuple,
> Size usable_bytes_per_page)
> ...
> * If the table has inheritance children, we don't apply this heuristic.
> * Totally empty parent tables are quite common, so we should be willing
> * to believe that they are empty.
> */
> if (curpages < 10 &&
> relpages == 0 &&
> !rel->rd_rel->relhassubclass)
> curpages = 10;
>
> which'd not make us actually take a relpages=0 into account for tables
> without inheritance. A lot of these tables never get 10+ pages long, so
> the heuristic would always apply...

Surely it can't be that since that just sets what *pages gets set to.
Tom mentioned that following was returning 0 pages and tuples:

-- Temporary hack to investigate whether extra vacuum/analyze is happening
select relname, relpages, reltuples
from pg_class
where relname like '__star' order by relname;
relname | relpages | reltuples
---------+----------+-----------
a_star | 1 | 3

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services