Re: UPDATE of partition key

From: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UPDATE of partition key
Date: 2017-09-22 05:57:02
Message-ID: CAJ3gD9fzD4jBpv+zXqZYnW=h9JXUFG9E7NGdA9gR_JJbOj=Q5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I have extracted a couple of changes into preparatory patches, as
explained below :

On 20 September 2017 at 21:27, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> On 20 September 2017 at 00:06, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Sep 15, 2017 at 7:25 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
>>> [ new patch ]
>>
>> This already fails to apply again. In general, I think it would be a
>> good idea to break this up into a patch series rather than have it as
>> a single patch. That would allow some bits to be applied earlier.
>> The main patch will probably still be pretty big, but at least we can
>> make things a little easier by getting some of the cleanup out of the
>> way first. Specific suggestions on what to break out below.
>>
>> If the changes to rewriteManip.c are a marginal efficiency hack and
>> nothing more, then let's commit this part separately before the main
>> patch. If they're necessary for correctness, then please add a
>> comment explaining why they are necessary.
>
> Ok. Yes, just wanted to avoid two ConvertRowtypeExpr nodes one over
> the other. But that was not causing any correctness issue. Will
> extract these changes into separate patch.

The patch for the above change is :
0002-Prevent-a-redundant-ConvertRowtypeExpr-node.patch

>
>>
>> There appears to be no reason why the definitions of
>> GetInsertedColumns() and GetUpdatedColumns() need to be moved to a
>> header file as a result of this patch. GetUpdatedColumns() was
>> previously defined in trigger.c and execMain.c and, post-patch, is
>> still called from only those files. GetInsertedColumns() was, and
>> remains, called only from execMain.c. If this were needed I'd suggest
>> doing it as a preparatory patch before the main patch, but it seems we
>> don't need it at all.
>
> In earlier versions of the patch, these functions were used in
> nodeModifyTable.c as well. Now that those calls are not there in this
> file, I will revert back the changes done for moving the definitions
> into header file.

Did the above , and included in the attached revised patch
update-partition-key_v19.patch.

>
>>
>> If I understand correctly, the reason for changing mt_partitions from
>> ResultRelInfo * to ResultRelInfo ** is that, currently, all of the
>> ResultRelInfos for a partitioning hierarchy are allocated as a single
>> chunk, but we can't do that and also reuse the ResultRelInfos created
>> during InitPlan. I suggest that we do this as a preparatory patch.
>
> Ok, will prepare a separate patch. Do you mean to include in that
> patch the changes I did in ExecSetupPartitionTupleRouting() that
> re-use the ResultRelInfo structures of per-subplan update result rels
> ?

Above changes are in attached
0001-Re-use-UPDATE-result-rels-created-in-InitPlan.patch.

Patches are to be applied in this order :

0001-Re-use-UPDATE-result-rels-created-in-InitPlan.patch
0002-Prevent-a-redundant-ConvertRowtypeExpr-node.patch
update-partition-key_v19.patch

--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company

Attachment Content-Type Size
0001-Re-use-UPDATE-result-rels-created-in-InitPlan.patch application/octet-stream 16.9 KB
0002-Prevent-a-redundant-ConvertRowtypeExpr-node.patch application/octet-stream 3.5 KB
update-partition-key_v19.patch application/octet-stream 109.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-09-22 06:00:20 Re: GUC for cleanup indexes threshold.
Previous Message Kyotaro HORIGUCHI 2017-09-22 05:52:53 Re: analyzeCTE is too strict about typmods?