| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE |
| Date: | 2021-04-19 15:59:00 |
| Message-ID: | CA+TgmoYGp6rJrE1eZZ8CfbPTctKb1V+7ZjuvYu14rmKmR9oJ2Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 19, 2021 at 10:34 AM Amit Langote <amitlangote09(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PegoraroF10 | 2021-04-19 16:01:06 | Re: More info on pg_stat_activity Wait Event Name when is DataFileRead |
| Previous Message | Tom Lane | 2021-04-19 15:57:25 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |