Re: The documentation for storage type 'plain' actually allows single byte header

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, suchithjn22(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: The documentation for storage type 'plain' actually allows single byte header
Date: 2023-01-16 01:08:01
Message-ID: 20230116010801.ap5agt2yhoflik3o@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

Hi,

On 2023-01-15 16:49:01 -0800, Andres Freund wrote:
> I don't see how we can fix this mess entirely without tracking the storage
> type a lot more widely. Most importantly in targetlists, as we use the
> targetlists to compute the tupledescs of executor nodes, which then influence
> where we build projections.
>
>
> Given that altering a column to PLAIN doesn't rewrite the table, we already
> have to be prepared to receive short or compressed varlenas, even after
> setting STORAGE to PLAIN.
>
> I think we should consider just reformulating the "furthermore it disables use
> of single-byte headers for varlena types" portion to say that short varlenas
> are disabled for non-toastable datatypes. I don't see much point in investing
> a lot of complexity making this a hard restriction. Afaict the only point in
> changing to PLAIN is to disallow external storage and compression, which it
> achieves eved when using short varlenas.
>
> The compression bit is a bit worse, I guess. We probably have the same problem
> with EXTERNAL, which supposedly doesn't allow compression - but I don't think
> we have code ensuring that we decompress in-line datums. It'll end up
> happening if there's other columns that get newly compressed or stored
> externally, but not guaranteed.

One way we could deal with it would be to force the tuple to be processed by
heap_toast_insert_or_update() when there's a difference between typstorage and
attstorage. I think to make that cheap enough to determine, we'd have to cache
that information in the relcache. I haven't thought it through, but I suspect
it'd be problematic to add a pg_type lookup to RelationBuildTupleDesc(),
leading to building that information on demand later.

Greetings,

Andres Freund

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Laurenz Albe 2023-01-16 13:07:48 Re: The documentation for storage type 'plain' actually allows single byte header
Previous Message Andres Freund 2023-01-16 00:49:01 Re: The documentation for storage type 'plain' actually allows single byte header

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-01-16 01:28:23 Re: Exit walsender before confirming remote flush in logical replication
Previous Message Andres Freund 2023-01-16 00:49:01 Re: The documentation for storage type 'plain' actually allows single byte header