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