| From: | Arne Roland <A(dot)Roland(at)index(dot)de> |
|---|---|
| To: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Partial join |
| Date: | 2019-08-01 08:07:25 |
| Message-ID: | dd01626a46a342f7b1d811cf38fcebe6@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? Do you have better ideas?
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 | Thomas Munro | 2019-08-01 08:08:15 | Re: using explicit_bzero |
| Previous Message | Richard Guo | 2019-08-01 07:19:44 | Re: How to retain lesser paths at add_path()? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2019-08-01 11:14:44 | Re: Partial join |
| Previous Message | Shital A | 2019-08-01 05:18:10 | Re: PSQL performance - TPS |