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 |
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 |