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
-
Comment cleanup for a1115fa07.
- 0d46771eaaf7 14.0 landed
-
Postpone some more stuff out of ExecInitModifyTable.
- a1115fa07823 14.0 landed
-
Postpone some stuff out of ExecInitModifyTable.
- c5b7ba4e67ae 14.0 landed