Re: BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: mba(dot)ogolny(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds
Date: 2020-07-28 15:32:56
Message-ID: 1195168.1595950376@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> Consider the following setup of empty tables partitioned first by `key1` and
> then by `key2`:
> ...
> EXPLAIN ANALYZE
> SELECT *
> FROM demo1
> JOIN demo2 ON demo1.key2 = demo2.key2
> WHERE demo1.key2 = 123
> AND demo2.key2 = 123
> AND FALSE;

What seems to be happening here is that expression simplification reduces
the WHERE clause to just constant-false, ie

SELECT * FROM demo1 JOIN demo2 ON demo1.key2 = demo2.key2 WHERE FALSE;

and then, because there are no constraints that the partitioning logic can
use to recognize that it need only consider a few of the partitions, it
proceeds to generate a plan joining the entire partition trees. The
individual elements of the plan get thrown away later due to the WHERE
FALSE, but not before we've expended cycles considering them; so the
planning time is not much different from what it'd be if you had no
WHERE at all.

I'm disinclined to consider this an interesting case, frankly.
It's more an example of the documented fact that we're not very
good yet with large numbers of partitions.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message tutiluren 2020-07-28 22:40:46 Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.
Previous Message Devrim Gündüz 2020-07-28 13:29:05 Re: BUG #16459: YUM pgdg11-updates-debuginfo repository missing repodata/repomd.xml for RHEL8*