From: | Rob Sargentg <robjsargent(at)gmail(dot)com> |
---|---|
To: | Dorian Hoxha <dorian(dot)hoxha(at)gmail(dot)com> |
Cc: | Fede Martinez <federicoemartinez(at)gmail(dot)com>, PostgreSql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Altering array(composite-types) without breaking code when inserting them and similar questions |
Date: | 2014-04-21 02:02:51 |
Message-ID: | 53547C4B.4080208@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Sorry, I should not have top-posted (Dang iPhone). Continued below:
On 04/20/2014 05:54 PM, Dorian Hoxha wrote:
> Because i always query the whole row, and in the other way(many
> tables) i will always join + have other indexes.
>
>
> On Sun, Apr 20, 2014 at 8:56 PM, Rob Sargent <robjsargent(at)gmail(dot)com
> <mailto:robjsargent(at)gmail(dot)com>> wrote:
>
> Why do you think you need an array of theType v. a dependent table
> of theType. This tack is of course immune to to most future type
> changess.
>
> Sent from my iPhone
>
Interesting. Of course any decent mapper will return "the whole row".
And would it be less disk intensive as an array of "struct ( where
struct is implemented as an array)". From other threads [1] [2] I've
come to understand the datatype overhead per native type will be applied
per type instance per array element.
[1] 30K floats
<http://postgresql.1045698.n5.nabble.com/Is-it-reasonable-to-store-double-arrays-of-30K-elements-td5790562.html>
[2] char array
<http://postgresql.1045698.n5.nabble.com/COPY-v-java-performance-comparison-tc5798389.html>
From | Date | Subject | |
---|---|---|---|
Next Message | Fenn Bailey | 2014-04-21 03:19:44 | Re: Non-deterministic 100% CPU hang on postgres 9.3 |
Previous Message | Dorian Hoxha | 2014-04-20 23:54:09 | Re: Altering array(composite-types) without breaking code when inserting them and similar questions |