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
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 |