From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Phil Currier <pcurrier(at)gmail(dot)com> |
Subject: | Re: logical column ordering |
Date: | 2014-12-10 00:15:25 |
Message-ID: | 5487909D.3040806@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/09/2014 06:19 PM, Josh Berkus wrote:
> On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
>> The first thing where this matters is tuple descriptor expansion in
>> parse analysis; at this stage, things such as "*" (in "select *") are
>> turned into a target list, which must be sorted according to attlognum.
>> To achieve this I added a new routine to tupledescs,
> The two other major cases are:
>
> INSERT INTO table SELECT|VALUES ...
>
> COPY table FROM|TO ...
>
> ... although copy should just be a subclass of SELECT.
>
> Question on COPY, though: there's reasons why people would want COPY to
> dump in either physical or logical order. If you're doing COPY to
> create CSV files for output, then you want the columns in logical order.
> If you're doing COPY for pg_dump, then you want them in physical order
> for faster dump/reload. So we're almost certainly going to need to have
> an option for COPY.
>
>
I seriously doubt it, although I could be wrong. Unless someone can show
a significant performance gain from using physical order, which would be
a bit of a surprise to me, I would just stick with logical ordering as
the default.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-12-10 00:16:47 | Re: group locking: incomplete patch, just for discussion |
Previous Message | Michael Paquier | 2014-12-09 23:31:34 | Re: Proposal : REINDEX SCHEMA |