Re: Should total_pages be calculated after partition pruning and constraint exclusion?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Should total_pages be calculated after partition pruning and constraint exclusion?
Date: 2018-05-16 15:00:28
Message-ID: 11304.1526482828@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On 16 May 2018 at 11:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Grigory Smolkin 2018-05-16 15:09:03 Re: libpq compression
Previous Message Robert Haas 2018-05-16 14:57:16 Re: log_min_messages shows debug instead of debug2