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 to
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 order in
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
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
On 2/21/07, Martijn van Oosterhout kleptog@svana.org 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
On 2/21/07, Martijn van Oosterhout kleptog@svana.org 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
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
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
