Re: ModifyTable overheads in generic plans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ModifyTable overheads in generic plans
Date
Msg-id 1596686.1617813279@sss.pgh.pa.us
Whole thread Raw
In response to Re: ModifyTable overheads in generic plans  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: ModifyTable overheads in generic plans
Re: ModifyTable overheads in generic plans
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> Also, I think we should update the commentary around ri_projectNew a
> bit to make it clear that noplace beside ExecGet{Insert|Update}Tuple
> should be touching it and the associated slots.

Hm.  I pushed your comment fixes in nodeModifyTable.c, but not this
change, because it seemed to be more verbose and not really an
improvement.  Why are these fields any more hands-off than any others?
Besides which, there certainly is other code touching ri_oldTupleSlot.

Anyway, I've marked the CF entry closed, because I think this is about
as far as we can get for v14.  I'm not averse to revisiting the
RETURNING and WITH CHECK OPTIONS issues later, but it looks to me like
that needs more study.

> I reran my usual benchmark and got the following numbers, this time
> comparing v13.2 against the latest HEAD:

> nparts  10cols      20cols      40cols

> v13.2
> 64      3231        2747        2217
> 128     1528        1269        1121
> 256     709         652         491
> 1024    96          78          67

> v14dev HEAD
> 64      14835       14360       14563
> 128     9469        9601        9490
> 256     5523        5383        5268
> 1024    1482        1415        1366

> Clearly, we've made some very good progress here.  Thanks.

Indeed, that's a pretty impressive comparison.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: multi-install PostgresNode fails with older postgres versions
Next
From: "David G. Johnston"
Date:
Subject: Re: Need help!