Re: ModifyTable overheads in generic plans

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL-development <pgsql-hackers@postgresql.org>, David Rowley <dgrowleyml@gmail.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Date: 2021-04-07T18:02:16Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 7, 2021 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Indeed, that's a pretty impressive comparison.

> +1. That looks like a big improvement.

> In a vacuum, you'd hope that partitioning a table would make things
> faster rather than slower, when only one partition is implicated. Or
> at least that the speed would stay about the same. And, while this is
> a lot better, we're clearly not there yet. So I hope that, in future
> releases, we can continue to find ways to whittle down the overhead.

Note that this test case includes plan_cache_mode = force_generic_plan,
so it's deliberately kneecapping our ability to tell that "only one
partition is implicated".  I think things would often be better in
production cases.  No argument that there's not work left to do, though.

			regards, tom lane



Commits

  1. Comment cleanup for a1115fa07.

  2. Postpone some more stuff out of ExecInitModifyTable.

  3. Postpone some stuff out of ExecInitModifyTable.