Re: ModifyTable overheads in generic plans

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