Andrew Dunstan wrote:
>
> 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 ...
Yes, both are covered.
> >... although copy should just be a subclass of SELECT.
It is not. There's one part of COPY that goes through SELECT
processing, but only when the "table" being copied is a subselect.
Normal COPY does not use the same code path.
> >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.
Well, we have an optimization that avoids a projection step IIRC by
using the "physical tlist" instead of having to build a tailored one. I
guess the reason that's there is because somebody did measure an
improvement. Maybe it *is* worth having as an option for pg_dump ...
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
