|From:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: speeding up planning with partitions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019/02/21 11:31, Amit Langote wrote:
> On 2019/02/21 0:50, Tom Lane wrote:
>> There might be parts of this work we can salvage, though. It seems
>> like the idea of postponing expand_inherited_tables() might be
>> something we could use anyway.
> +1. So, let's try to do things in this order:
> 1. Make inheritance-expansion-at-bottom case perform better now,
> addressing at least SELECT performance in PG 12, provided we manage to get
> the patches in order in time (I'll try to post the updated
> lazy-inheritance-expansion patch later this week.)
I have updated the inheritance expansion patch.
Patch 0001 rewrites optimizer/utils/inherit.c, so that it allows
inheritance expansion to be invoked from make_one_rel(). Although the
rewrite in this version of the patch is a bit different from earlier
versions, because I needed to account for the fact that
inheritance_planner (whose rewrite I'm withdrawing) will use the same
expansion code to expand target inheritance. So, the code now needs to
treat source-inheritance-expansion and target-inheritance-expansion cases
a bit differently.
I wanted to polish the code and various comments a bit more because the
rewritten expansion code looks different from earlier versions as I
mentioned above, but I needed to rush out today due to a family emergency
and won't be able to reply until Wednesday next week. Sorry.
|Next Message||Claudio Freire||2019-02-22 13:34:42||Re: Using old master as new replica after clean switchover|
|Previous Message||Pavel Stehule||2019-02-22 12:42:37||Re: proposal: variadic argument support for least, greatest function|