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
