From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, sanyo(dot)moura(at)tatic(dot)net, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, David Rowley <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-11 11:10:44 |
Message-ID: | 5C3879B4.8000605@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
(2019/01/11 13:49), Amit Langote wrote:
> On 2019/01/11 11:21, Etsuro Fujita wrote:
>> (2019/01/10 21:23), Amit Langote wrote:
>>> On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
>>> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>>>> Though this will solve a problem for performance when partition-wise
>>>> join is not possible, we still have the same problem when
>>>> partition-wise join is possible. And that problem really happens
>>>> because our inheritance mechanism requires expression translation from
>>>> parent to child everywhere. That consumes memory, eats CPU cycles and
>>>> generally downgrades performance of partition related query planning. I
>>>> think a better way would be to avoid these translations and use Parent
>>>> var to represent a Var of the child being dealt with. That will be a
>>>> massive churn on inheritance based planner code, but it will improve
>>>> planning time for queries involving thousands of partitions.
>>>
>>> Yeah, it would be nice going forward to overhaul inheritance planning
>>> such that parent-to-child Var translation is not needed, especially
>>> where no pruning can occur or many partitions remain even after
>>> pruning.
>>
>> I agree on that point, but I think that's an improvement for a future
>> release rather than a fix for the issue reported on this thread.
>
> Agreed.
Cool!
> Improving planning performance for large number of partitions
> even in the absence of pruning is a good goal to pursue for future
> versions, as is being discussed in some other threads [1].
Yeah, we have a lot of challenges there. Thanks for sharing the info!
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Hubert Zhang | 2019-01-11 11:14:50 | Re: Discussion: Fast DB/Schema/Table disk size check in Postgresql |
Previous Message | Thomas Munro | 2019-01-11 11:06:18 | Three animals fail test-decoding-check on REL_10_STABLE |
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2019-01-11 12:50:19 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |
Previous Message | Etsuro Fujita | 2019-01-11 11:04:40 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |