Message-ID: <5C3879B4.8000605@lab.ntt.co.jp>
Date: Fri, 11 Jan 2019 20:10:44 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: Re: Query with high planning time at version 11.1 compared versions
 10.5 and 11.0
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>
In-Reply-To: <acd3b89f-efe4-4760-5897-8542fddeaf68@lab.ntt.co.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Amit Langote <amitlangote09@gmail.com>,
        Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Justin Pryzby <pryzby@telsasoft.com>, sanyo.moura@tatic.net,
        Jeff Janes <jeff.janes@gmail.com>,
        David Rowley <david.rowley@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Precedence: bulk

(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