On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@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
