Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE
Date
Msg-id CA+TgmoYGp6rJrE1eZZ8CfbPTctKb1V+7ZjuvYu14rmKmR9oJ2Q@mail.gmail.com
Whole thread Raw
In response to Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Apr 19, 2021 at 10:34 AM Amit Langote <amitlangote09@gmail.com> wrote:
> After 86dc90056, the new tuple is computed with the target table's
> actual TupleDesc, so the new value respects the column's attstorage,
> which makes me think the new behavior is not wrong.

I would not have expected SET STORAGE PLAIN to disable the use of
short varlena headers. *Maybe* at some point in time there was enough
code that couldn't operate directly on short varlenas to justify a
theory that in some circumstances eschewing short headers would save
on CPU cycles. But surely in 2021 this is not true and this behavior
is not plausibly desired by anyone.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Next
From: PegoraroF10
Date:
Subject: Re: More info on pg_stat_activity Wait Event Name when is DataFileRead