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

On 16 May 2018 at 11:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
>> On 16 May 2018 at 08:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
>>> Please add to next CF. It's a bit late to be doing such things in v11,
>>> IMO.
>
>> If I do that, it'll go under bug fix.
>
> 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. But for a more direct
> analogy, if you'd submitted some other improvement in selectivity
> or cost estimation, that was not a bug fix in the sense of "corrects
> outright wrong answers", would you expect it to escape feature freeze
> at this point?

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. I wouldn't have pushed a
backpatch due to possible plan destabilisation. People may have pushed
effective_cache_size beyond their machines RAM size to work around it.

I'll add to the commitfest before it opens., if it's going in as
"planner improvement" I'll probably hold off until I'm ready with the
other improvements that I'm working on.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services