From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: sanyo.moura@tatic.net, Jeff Janes <jeff.janes@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
Date: Fri, 11 Jan 2019 20:10:44 +0900
Message-ID: <5C3879B4.8000605@lab.ntt.co.jp> (raw)
In-Reply-To: <acd3b89f-efe4-4760-5897-8542fddeaf68@lab.ntt.co.jp>
References: <8db4eca8-6e76-70ff-f934-e0228a1cc298@lab.ntt.co.jp>
<20181206075726.pig32e6thltb56hr@alvherre.pgsql>
<CAExHW5umxU5FOoT8FBcqp-GWKMtZhnuEy7U6bNH8QfzvYwUgEQ@mail.gmail.com>
<CAExHW5uFwP_1N7RV6s8piQBvygGH+rppS60nFNHB9DKEM04ShA@mail.gmail.com>
<5C34846E.9090600@lab.ntt.co.jp>
<96720c99-ffa0-01ad-c594-0504c8eda708@lab.ntt.co.jp>
<5C35D912.8040200@lab.ntt.co.jp>
<7354b5bf-5932-4c0c-81ee-d9550de18995@lab.ntt.co.jp>
<CAExHW5udpeQNPgohGA5y5LsfiB9eWBw18yMq_O0eSsby-f4rzg@mail.gmail.com>
<CA+HiwqHyZSU_6+d3dPtA2Vb3BBH4pAG9zbQ0Yu9kbUOq7N5BnA@mail.gmail.com>
<5C37FD8D.4080302@lab.ntt.co.jp>
<acd3b89f-efe4-4760-5897-8542fddeaf68@lab.ntt.co.jp>
(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.bapat.oss@gmail.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: fujita.etsuro@lab.ntt.co.jp, Langote_Amit_f8@lab.ntt.co.jp, amitlangote09@gmail.com, ashutosh.bapat.oss@gmail.com, alvherre@2ndquadrant.com, pryzby@telsasoft.com, jeff.janes@gmail.com, david.rowley@2ndquadrant.com, robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
In-Reply-To: <5C3879B4.8000605@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox