Re: non-bulk inserts and tuple routing

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: non-bulk inserts and tuple routing
Date: 2018-03-03 04:38:18
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2018-02-22 11:10:57 -0500, Robert Haas wrote:
> On Tue, Feb 20, 2018 at 8:06 PM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >> Attached is an updated version for that.
> >
> > Thanks for updating the patch.
> Committed with a few changes. The big one was that I got rid of the
> local variable is_update in ExecSetupPartitionTupleRouting. That
> saved a level of indentation on a substantial chunk of code, and it
> turns out that test was redundant anyway.

I noticed that this patch broke my JIT patch when I force JITing to be
used everywhere (obviously pointless for perf reasons, but good for
testing). Turns out to be a single line.

ExecInitPartitionInfo has the following block:
foreach(ll, wcoList)
WithCheckOption *wco = castNode(WithCheckOption, lfirst(ll));
ExprState *wcoExpr = ExecInitQual(castNode(List, wco->qual),

wcoExprs = lappend(wcoExprs, wcoExpr);

note how it is passing mtstate->mt_plans[0] as the parent node for the
expression. I don't quite know why mtstate->mt_plans[0] was chosen
here, it doesn't seem right. The WCO will not be executed in that
context. Note that the ExecBuildProjectionInfo() call a few lines below
also uses a different context.

For JITing that fails because the compiled deform will assume the tuples
look like mt_plans[0]'s scantuples. But we're not dealing with those,
we're dealing with tuples returned by the relevant subplan.

Also note that the code before this commit used
ExprState *wcoExpr = ExecInitQual(castNode(List, wco->qual),
i.e. the ModifyTableState node, as I'd expect.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-03-03 04:45:14 Re: heap_lock_updated_tuple_rec can leak a buffer refcount
Previous Message Mark Kirkwood 2018-03-03 04:05:28 Re: zheap: a new storage format for PostgreSQL