Re: UPDATE of partition key

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>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UPDATE of partition key
Date: 2017-07-04 08:25:17
Message-ID: e2a12f49-9abc-c9b2-14b3-41c19af4be01@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/07/03 18:54, Amit Langote wrote:
> On 2017/07/02 20:10, Robert Haas wrote:

>> But that seems like it wouldn't be too hard to fix: let's have
>> expand_inherited_rtentry() expand the partitioned table in the same
>> order that will be used by ExecSetupPartitionTupleRouting().

That's really what I wanted when updating the patch for tuple-routing to
foreign partitions. (I don't understand the issue discussed here, though.)

>> That
>> seems pretty easy to do - just have expand_inherited_rtentry() notice
>> that it's got a partitioned table and call
>> RelationGetPartitionDispatchInfo() instead of find_all_inheritors() to
>> produce the list of OIDs.
Seems like a good idea.

> Interesting idea.
>
> If we are going to do this, I think we may need to modify
> RelationGetPartitionDispatchInfo() a bit or invent an alternative that
> does not do as much work. Currently, it assumes that it's only ever
> called by ExecSetupPartitionTupleRouting() and hence also generates
> PartitionDispatchInfo objects for partitioned child tables. We don't need
> that if called from within the planner.
>
> Actually, it seems that RelationGetPartitionDispatchInfo() is too coupled
> with its usage within the executor, because there is this comment:
>
> /*
> * We keep the partitioned ones open until we're done using the
> * information being collected here (for example, see
> * ExecEndModifyTable).
> */

Yeah, we need some refactoring work. Is anyone working on that?

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2017-07-04 08:55:29 Update comment in ExecPartitionCheck
Previous Message Michael Paquier 2017-07-04 07:53:51 Re: hash index on unlogged tables doesn't behave as expected