Re: Storage for multiple variable-length attributes in a single row - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Storage for multiple variable-length attributes in a single row
Date
Msg-id CAKFQuwZ8X5shoC1U05ob8DEWuhyyf7D+QGxFkeOVBADRPWYR7Q@mail.gmail.com
Whole thread Raw
In response to Re: Storage for multiple variable-length attributes in a single row  (Esteban Zimanyi <esteban.zimanyi@ulb.be>)
Responses Re: Storage for multiple variable-length attributes in a single row  (Esteban Zimanyi <estebanzimanyi@gmail.com>)
List pgsql-hackers
On Mon, Feb 7, 2022 at 8:44 AM Esteban Zimanyi <esteban.zimanyi@ulb.be> wrote:
May I kindly ask your insight about a question I posted 1 month ago and for which I never received any answer ?

-hackers really isn't the correct place for usage questions like this - even if you are creating a custom type (why you are doing this is left unstated, I have no idea what it means to be a temporally extended version of boolean, etc...)

You should read up on how TOAST works in PostgreSQL since that is what handles large length data values.

IIUC your setup correctly, you are claiming to have 2k or more columns.  This well exceeds the limit for PostgreSQL.
A "tablespace" is a particular functionality provided by the server.   You are using "table space" in a different sense and I'm unsure exactly what you mean.  I presume "cell".  PostgreSQL has row-oriented storage (our internals documentation goes over this).

I think your mention of mobilitydb also complicates receiving a useful response as this list is for the core project.  That you can exceed the column count limit suggests that your environment is enough different than core that you should be asking there.

You will need to await someone else to specifically answer the extended storage question though - but I suspect you've provided insufficient details in that regard.

David J.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade should truncate/remove its logs before running
Next
From: Julien Rouhaud
Date:
Subject: Re: Database-level collation version tracking