Re: making update/delete of inheritance trees scale better

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: making update/delete of inheritance trees scale better
Date: 2020-10-30 22:12:19
Message-ID: 141158.1604095939@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-10-30 22:20:16 Re: contrib/sslinfo cleanup and OpenSSL errorhandling
Previous Message Heikki Linnakangas 2020-10-30 22:09:32 Re: Parallel copy