Re: ModifyTable overheads in generic plans

Amit Langote <amitlangote09(at)gmail(dot)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