From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Phil Currier <pcurrier(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Column storage positions |
Date: | 2007-02-21 22:37:05 |
Message-ID: | 45DCC991.10501@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Florian G. Pflug wrote:
>
> BTW, this is a good case for why the storage order should - directly or
> indirectly - be tweakable. You can either optimize for space, and _then_
> for speed - which is what the OP did I think - or first for speed, and
> then for space. If the dba cannot choose the strategy, there will
> always be workloads where the engine does it the wrong way around.
>
>
Maybe a simple setting on ordering strategy would be OK. The chance of
mucking it up if you can directly set the physical order seems just too
great to me.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-02-21 22:38:02 | Re: Column storage positions |
Previous Message | Alvaro Herrera | 2007-02-21 22:29:48 | Re: [previously on HACKERS] "Compacting" a relation |