Re: Storage for multiple variable-length attributes in a single row

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Esteban Zimanyi <esteban(dot)zimanyi(at)ulb(dot)be>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, SAKR Mahmoud <mahmoud(dot)sakr(at)ulb(dot)be>
Subject: Re: Storage for multiple variable-length attributes in a single row
Date: 2022-02-07 16:04:57
Message-ID: CAKFQuwZ8X5shoC1U05ob8DEWuhyyf7D+QGxFkeOVBADRPWYR7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 7, 2022 at 8:44 AM Esteban Zimanyi <esteban(dot)zimanyi(at)ulb(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-02-07 16:08:14 Re: Database-level collation version tracking
Previous Message Andrew Dunstan 2022-02-07 16:00:22 Re: pg_upgrade should truncate/remove its logs before running