Re: making update/delete of inheritance trees scale better
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-02-04T13:40:52Z
Lists: pgsql-hackers
On Thu, Feb 4, 2021 at 4:33 AM Amit Langote <amitlangote09@gmail.com> wrote: > So would zheap refetch a tuple using the "ctid" column in the plan's > output tuple and then use some other columns from the fetched tuple to > actually do the update? Yes. > To be clear, the new refetch in ExecModifyTable() is to fill in the > unchanged columns in the new tuple. If we rejigger the > table_tuple_update() API to receive a partial tuple (essentially > what's in 'planSlot' passed to ExecUpdate) as opposed to the full > tuple, we wouldn't need the refetch. I don't think we should assume that every AM needs the unmodified columns. Imagine a table AM that's a columnar store. Imagine that each column is stored completely separately, so you have to look up the TID once per column and then stick in the new values. Well, clearly you want to skip this completely for columns that don't need to be modified. If someone gives you all the columns it actually sucks, because now you have to look them all up again just to figure out which ones you need to change, whereas if they gave you only the unmodified columns you could just do nothing for those and save a bunch of work. zheap, though, is always going to need to take another look at the tuple to do the update, unless you can pass up some values through hidden columns. I'm not exactly sure how expensive that really is, though. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Rework planning and execution of UPDATE and DELETE.
- 86dc90056dfd 14.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited