Re: making update/delete of inheritance trees scale better
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Amit Langote <amitlangote09@gmail.com>,
Robert Haas <robertmhaas@gmail.com>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-10-30T22:12:19Z
Lists: pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes: > .... But if you do: > postgres=# explain verbose update tab set a = 1, b = 2; > QUERY PLAN > --------------------------------------------------------------------------------- > Update on public.tab (cost=0.00..269603.27 rows=0 width=0) > -> Seq Scan on public.tab (cost=0.00..269603.27 rows=10028327 > width=14) > Output: 1, 2, ctid > The Modify Table will still fetch the old tuple, but in this case, it's > not really necessary, because both columns are overwritten. Ah, that I believe. Not sure it's a common enough case to spend cycles looking for, though. In any case, we still have to access the old tuple, don't we? To lock it and update its t_ctid, whether or not we have use for its user columns. Maybe there's some gain from not having to deconstruct the tuple, but it doesn't seem like it'd be much. regards, tom lane
Commits
-
Rework planning and execution of UPDATE and DELETE.
- 86dc90056dfd 14.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited