| From: | Arne Roland <A(dot)Roland(at)index(dot)de> |
|---|---|
| To: | "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Partial join |
| Date: | 2019-07-29 16:43:05 |
| Message-ID: | 9dc03e949e9b4327a0d074da9ab44318@index.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Hello,
I attached one example of a partitioned table with multi column partition key. I also attached the output.
Disabling the hash_join is not really necessary, it just shows the more drastic result in the case of low work_mem.
Comparing the first and the second query I was surprised to see that SET enable_partitionwise_join could cause the costs to go up. Shouldn't the paths of the first query be generated as well?
The third query seems to have a different issue. That one is close to my original performance problem. It looks to me like the push down of the sl condition stops the optimizer considering a partial join.
If so would it be sane to keep a copy of the original quals to make the partial join possible?
Regards
Arne
| Attachment | Content-Type | Size |
|---|---|---|
| querys.sql | application/sql | 2.3 KB |
| explain_analyze.sql | application/sql | 7.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-07-29 16:58:17 | Re: SimpleLruTruncate() mutual exclusion |
| Previous Message | Robert Haas | 2019-07-29 16:35:25 | Re: should there be a hard-limit on the number of transactions pending undo? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jean Baro | 2019-07-29 18:09:08 | Re: High concurrency same row (inventory) |
| Previous Message | MichaelDBA | 2019-07-29 12:55:23 | Re: High concurrency same row (inventory) |