Re: Declarative partitioning - another take

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Erik Rijkers <er(at)xs4all(dot)nl>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: Declarative partitioning - another take
Date: 2016-12-27 08:59:05
Message-ID: f6f3a214-5bb5-aa8c-f82c-c720348cf086@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016/12/26 19:46, Amit Langote wrote:
> (Perhaps, the following should be its own new thread)
>
> I noticed that ExecProcessReturning() doesn't work properly after tuple
> routing (example shows how returning tableoid currently fails but I
> mention some other issues below):
>
> create table p (a int, b int) partition by range (a);
> create table p1 partition of p for values from (1) to (10);
> insert into p values (1) returning tableoid::regclass, *;
> tableoid | a | b
> ----------+---+---
> - | 1 |
> (1 row)
>
> INSERT 0 1
>
> I tried to fix that in 0007 to get:
>
> insert into p values (1) returning tableoid::regclass, *;
> tableoid | a | b
> ----------+---+---
> p | 1 |
> (1 row)
>
> INSERT 0 1
>
> But I think it *may* be wrong to return the root table OID for tuples
> inserted into leaf partitions, because with select we get partition OIDs:
>
> select tableoid::regclass, * from p;
> tableoid | a | b
> ----------+---+---
> p1 | 1 |
> (1 row)
>
> If so, that means we should build the projection info (corresponding to
> the returning list) for each target partition somehow. ISTM, that's going
> to have to be done within the planner by appropriate inheritance
> translation of the original returning targetlist.

Turns out getting the 2nd result may not require planner tweaks after all.
Unless I'm missing something, translation of varattnos of the RETURNING
target list can be done as late as ExecInitModifyTable() for the insert
case, unlike update/delete (which do require planner's attention).

I updated the patch 0007 to implement the same, including the test. While
doing that, I realized map_partition_varattnos introduced in 0003 is
rather restrictive in its applicability, because it assumes varno = 1 for
the expressions it accepts as input for the mapping. Mapping returning
(target) list required modifying map_partition_varattnos to accept
target_varno as additional argument. That way, we can map arbitrary
expressions from the parent attributes numbers to partition attribute
numbers for expressions not limited to partition constraints.

Patches 0001 to 0006 unchanged.

Thanks,
Amit

Attachment Content-Type Size
0001-Allocate-partition_tuple_slot-in-respective-nodes.patch text/x-diff 9.2 KB
0002-Make-ExecConstraints-show-the-correct-row-in-error-m.patch text/x-diff 13.7 KB
0003-Fix-a-bug-in-how-we-generate-partition-constraints.patch text/x-diff 14.2 KB
0004-Fix-a-bug-of-insertion-into-an-internal-partition.patch text/x-diff 6.7 KB
0005-Add-some-more-tests-for-tuple-routing.patch text/x-diff 5.2 KB
0006-Avoid-tuple-coversion-in-common-partitioning-cases.patch text/x-diff 5.0 KB
0007-Fix-RETURNING-to-work-correctly-after-tuple-routing.patch text/x-diff 10.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2016-12-27 09:05:42 Re: Patch: Write Amplification Reduction Method (WARM)
Previous Message Kyotaro HORIGUCHI 2016-12-27 08:25:46 Re: Fix checkpoint skip logic on idle systems by tracking LSN progress