| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pryzby(at)telsasoft(dot)com, sanyo(dot)moura(at)tatic(dot)net, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, david(dot)rowley(at)2ndquadrant(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |
| Date: | 2019-01-16 05:52:15 |
| Message-ID: | 5C3EC68F.8030202@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Hi Ashutosh,
(2019/01/15 13:29), Ashutosh Bapat wrote:
> I think, there's something better possible. Two partitioned relations
> won't use partition-wise join, if their partition schemes do not match.
> Partitioned relations with same partitioning scheme share
> PartitionScheme pointer. PartitionScheme structure should get an extra
> counter, maintaining a count of number of partitioned relations sharing
> that structure. When this counter is 1, that relation is certainly not
> going to participate in PWJ and thus need not have all the structure
> required by PWJ set up. If we use this counter coupled with
> enable_partitionwise_join flag, we can get rid of
> consider_partitionwise_join flag altogether, I think.
Interesting!
That flag was introduced to disable PWJs when whole-row Vars are
involved, as you know, so I think we need to first eliminate that
limitation, to remove that flag.
Thanks!
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2019-01-16 05:59:15 | Re: de-deduplicate code in DML execution hooks in postgres_fdw |
| Previous Message | Etsuro Fujita | 2019-01-16 05:45:16 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daulat Ram | 2019-01-16 07:06:00 | No matching tables have ever been vacuumed |
| Previous Message | Etsuro Fujita | 2019-01-16 05:45:16 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |