Re: Should total_pages be calculated after partition pruning and constraint exclusion? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should total_pages be calculated after partition pruning and constraint exclusion?
Date
Msg-id 11304.1526482828@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should total_pages be calculated after partition pruning andconstraint exclusion?  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 16 May 2018 at 11:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No, it should go under "planner improvement".  If this were a bug fix,
>> it'd be a candidate for back-patch, which IMO it's not --- if only
>> because of the risk of plan destabilization.

> I'm not going to make a fuss over it, but I guess we must differ in
> opinion as I would count tracking relation sizes of relations we're
> actually not going to scan as a bug.

Dunno, the way in which total_pages is used is so squishy/heuristic
that it's really hard to say that changing the way we calculate it
is necessarily going to lead to better plans.  I agree that this is
*probably* an improvement, but I don't think it's absolutely clear.

If there were some way to paint this as connected to other stuff
already done for v11, I'd be happier about pushing it in now --- but
it doesn't seem to be.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: log_min_messages shows debug instead of debug2
Next
From: Grigory Smolkin
Date:
Subject: Re: libpq compression