Re: BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds
От | Tom Lane |
---|---|
Тема | Re: BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds |
Дата | |
Msg-id | 1195168.1595950376@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.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
В списке pgsql-bugs по дате отправления: