Re: Parallel Append subplan order instability on aye-aye - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Parallel Append subplan order instability on aye-aye
Date
Msg-id 20190716192344.5jrt5pgzczi545zr@alap3.anarazel.de
Whole thread Raw
In response to Re: Parallel Append subplan order instability on aye-aye  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Parallel Append subplan order instability on aye-aye  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
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...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: rebased background worker reimplementation prototype
Next
From: Andres Freund
Date:
Subject: Re: refactoring - share str2*int64 functions