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

  1. Rework planning and execution of UPDATE and DELETE.

  2. Faster expression evaluation and targetlist projection.