Re: Planning time of Generic plan for a table partitioned into a lot

On Fri, 30 Nov 2018 at 15:04, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> On 2018/11/29 19:54, David Rowley wrote:
> > The problem is only made worse in PG11 from PG10
> > because generating the custom plan has become faster than it
> > previously was due to the new partition pruning code which might make
> > it appear we can handle more partitions than we could previously,
>
> Actually, PG 11's pruning improvements don't change plancache.c's equation
> of custom plan cost, that is, even if pruning may have gotten faster it
> doesn't change the value cached_plan_cost comes up with.

Unsure why you think I was implying that the plancache code had
changed. What I meant was, the faster pruning code means that PG11
appears more capable of handling more partitions than PG10 could
handle, but this really only goes as far as custom plans where many
partitions get pruned. When no pruning takes place, say, in a generic
plan where the partition key is being compared to some parameter, then
we've done nothing to improve the performance of planning for that.
This may result in someone doing some light testing and thinking PG11
can handle a higher number of partitions that we might advise them to
use, only to find themselves stumble later when trying to build a
generic plan for that number of partitions. It appears to me that
this is what's happened in this case.

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