Robert Haas wrote: > On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > >> Andrew Dunstan wrote: > >>> 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 ... > > > > The physical tlist thing is there because it's demonstrable that > > ExecProject() takes nonzero time. COPY does not go through ExecProject > > though. What's more, it already has code to deal with a user-specified > > column order, and nobody's ever claimed that that code imposes a > > measurable performance overhead. > > Also, if we're adding options to use the physical rather than the > logical column ordering in too many places, that's probably a sign > that we need to rethink this whole concept. The concept of a logical > column ordering doesn't have much meaning if you're constantly forced > to fall back to some other column ordering whenever you want good > performance.
FWIW I have no intention to add options for physical/logical ordering anywhere. All users will see is that tables will follow the same (logical) order everywhere. -- Á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