Horton

Re: ModifyTable overheads in generic plans

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL-development <pgsql-hackers@postgresql.org>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Date: 2021-04-08T04:54:39Z
Lists: pgsql-hackers 
On Thu, 8 Apr 2021 at 15:32, Amit Langote <amitlangote09@gmail.com> wrote:
> There's 10-20% improvement in this case too for various partition
> counts, which really has more to do with 86dc90056 than the work done
> here.

I'm not sure of the exact query you're running, but I imagine the
reason that it wasn't that slow with custom plans was down to
428b260f87.

So the remaining slowness for the generic plan case with large numbers
of partitions in the plan vs custom plans plan-time pruning is a)
locking run-time pruned partitions; and; b) permission checks during
executor startup?

Aside from the WCO and RETURNING stuff you mentioned, I mean.

David

Commits

  1. Comment cleanup for a1115fa07.

  2. Postpone some more stuff out of ExecInitModifyTable.

  3. Postpone some stuff out of ExecInitModifyTable.