Re: speeding up planning with partitions

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: Imai Yoshikazu <yoshikazu_i443(at)live(dot)jp>, "jesper(dot)pedersen(at)redhat(dot)com" <jesper(dot)pedersen(at)redhat(dot)com>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, "'Amit Langote'" <amitlangote09(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: speeding up planning with partitions
Date: 2019-03-27 04:50:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2019/03/27 12:06, Amit Langote wrote:
> I wonder if I should rework inherit.c so that its internal interfaces
> don't pass around parent Relation, but make do with the RelOptInfo? I'll
> need to add tupdesc and reltype fields to RelOptInfo to go ahead with that
> though.

To give more context on the last sentence, the only place we need the
TupleDesc for is make_inh_translation_list(). Maybe, instead of adding
tupdesc to RelOptInfo, we could add a List of Vars of all attributes of a
table. To avoid the overhead of always setting it, maybe we could set it
only for inheritance parent tables. Adding tupdesc to RelOptInfo might be
a hard sell to begin with, because it would need to be pinned and then
released at the end of planning.

I'll see if I can make this work.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-03-27 05:05:27 Re: Fix XML handling with DOCTYPE
Previous Message Tsunakawa, Takayuki 2019-03-27 04:41:05 RE: Libpq support to connect to standby server as priority