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
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 |