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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
