Robert Haas wrote:
> 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.
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
