Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

On Tue, Nov 27, 2018 at 11:36:09PM -0200, Sanyo Moura wrote:
> However, in the test I did in version 11.0, "Precio" is partitioned into
> only 21 partitions. So it really is a problem introduced in version 11, and
> it has to do with a large number of partitions in a table.

Thanks for confirming. My test works fine without FK CONSTRAINTs; as you said,
it's an issue of unreasonably high overhead of many partitions.

SELECT 'CREATE TABLE public.precio_'||i||' PARTITION OF public.precio (PRIMARY KEY (fecha, pluid, loccd) ) FOR VALUES FROM ('''||a||''')TO('''||b||''') ' FROM (SELECT '1990-01-01'::timestamp+(i||'days')::interval a, '1990-01-02'::timestamp+(i||'days')::interval b, i FROM generate_series(1,999) i)x;

This issue was discussed here:
https://www.postgresql.org/message-id/flat/94dd7a4b-5e50-0712-911d-2278e055c622%40dalibo.com

Which culminated in this commit.

|commit 7d872c91a3f9d49b56117557cdbb0c3d4c620687
|Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
|Date: Tue Jun 26 10:35:26 2018 -0400
|
| Allow direct lookups of AppendRelInfo by child relid

I tried with PG11.1 the test given here:
https://www.postgresql.org/message-id/CAKJS1f8qkcwr2DULd%2B04rBmubHkKzp4abuFykgoPUsVM-4-38g%40mail.gmail.com
with 999 partitions: Planning Time: 50.142 ms
with 9999 partitions: Planning Time: 239.284 ms
..close enough to what was reported.

So it seems there's something about your query which isn't handled as intended.

Adding relevant parties to Cc - find current thread here:
https://www.postgresql.org/message-id/flat/CAO698qZnrxoZu7MEtfiJmpmUtz3AVYFVnwzR%2BpqjF%3DrmKBTgpw%40mail.gmail.com

Justin