From: | Esteban Zimanyi <esteban(dot)zimanyi(at)ulb(dot)be> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | 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 15:52:22 |
Message-ID: | CAPqRbE7T23zgvf+qjboXpNev--LMxGsBZB-7sP4C+KsHJ=553A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear all
May I kindly ask your insight about a question I posted 1 month ago and for
which I never received any answer ?
Many thanks
On Thu, Jan 6, 2022 at 4:05 PM Esteban Zimanyi <esteban(dot)zimanyi(at)ulb(dot)be>
wrote:
> Dear all
>
> When ingesting mobility (IoT) data into MobilityDB
> https://mobilitydb.com/
> we transform very wide (2K attributes) car mobility data of high frequence
> (every tenth of a second) from flat format (e.g. CSV) into MobilityDB
> format in which there is a single record per trip and each of the signals
> is transformed into a temporal attribute (tbool, tint, tfloat, ttext,
> tgeompoint, tgeogpoint), which are temporal extensions of the corresponding
> PostgreSQL/PostGIS base types (bool, int, float, text, geometry,
> geography). All temporal types are stored using extended format, e.g.,
> CREATE TYPE tfloat (
> internallength = variable,
> [...]
> storage = extended,
> alignment = double,
> [...]
> );
>
> Given that each temporal value can be very wide (on average 30K
> timestamped points/floats/text/... per trip) our first question is
> * Is extended the right storage for this ?
>
> Our second question is how all the 2K temporal attributes are stored,
> which may be
> * on a single table space
> * in one table space per attribute
> which in other words, relates to the question row vs column storage.
>
> Many thanks for your insight
>
> Esteban
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-02-07 15:54:29 | Re: support for CREATE MODULE |
Previous Message | Peter Eisentraut | 2022-02-07 15:44:24 | Re: Database-level collation version tracking |