Horton

Re: ModifyTable overheads in generic plans

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <amitlangote09@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, David Rowley <dgrowleyml@gmail.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Date: 2021-04-07T00:00:25Z
Lists: pgsql-hackers 
Hi,

On 2021-04-06 19:24:11 -0400, Tom Lane wrote:
> I also could not get excited about postponing initialization of RETURNING
> or WITH CHECK OPTIONS expressions.  I grant that that can be helpful
> when those features are used, but I doubt that RETURNING is used that
> heavily, and WITH CHECK OPTIONS is surely next door to nonexistent
> in performance-critical queries.

FWIW, there's a number of ORMs etc that use it on every insert (there's
not really a better way to get the serial when you also want to do
pipelining).

> nparts	TPS
> 0	12152
> 10	8672
> 100	2753
> 1000	314
> 
> and after the two patches I just pushed, it looks like:
> 
> 0	12105
> 10	9928
> 100	5433
> 1000	938
> 
> So while there's certainly work left to do, that's not bad for
> some low-hanging-fruit grabbing.

Nice. 3x at the upper end is pretty good.

Greetings,

Andres Freund

Commits

  1. Comment cleanup for a1115fa07.

  2. Postpone some more stuff out of ExecInitModifyTable.

  3. Postpone some stuff out of ExecInitModifyTable.