Re: Parallel Append subplan order instability on aye-aye

On Wed, 17 Jul 2019 at 07:23, Andres Freund <andres@anarazel.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