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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers