On 4/1/07, Guillaume Smet <[EMAIL PROTECTED]> wrote:
Phil, did you make any progress with your patch? Your results seemed
very encouraging and your implementation interesting.
IIRC, the problem was that you weren't interested in working on the
"visual/mysqlish" column ordering. As the plan was t
On 2/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Right, I'm not advocating not doing that -- I'm just saying that the
>> first step to that could be decoupling physical position with attr id
>> :-) Logical column ordering (the o
On 2/21/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
So yes, there would be a use case for specifying the physical column layout
when pg_migrator is doing the pg_dump/restore. But pg_migrator could probably
just update the physical column numbers itself. It's not like updating system
catalog tabl
On 2/21/07, Martijn van Oosterhout wrote:
> don't see any good way to perform an upgrade between PG versions
> without rewriting each table's data. Maybe most people aren't doing
> upgrades like this right now, but it seems like it will only become
> more common in the future. In my opinion, t
On 2/21/07, Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 03:59:12PM +0100, Florian G. Pflug wrote:
> I think you'd want to have a flag per field that tell you if the user
> has overridden the storage pos for that specific field. Otherwise,
> the next time you have to chance to optimize
On 2/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Keep in mind we have a patch in process to reduce the varlena length and
reduce alignment requirements, so once that is in, reordering columns
will not be as important.
Well, as I understand it, that patch isn't really addressing the same
pro
On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort the columns to the most
efficient order; ALTER TABLE ADD COLU
Inspired by this thread [1], and in particular by the idea of storing
three numbers (permanent ID, on-disk storage position, display
position) for each column, I spent a little time messing around with a
prototype implementation of column storage positions to see what kind
of difference it would m
