| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Phil Currier <pcurrier(at)gmail(dot)com> |
| Subject: | Re: logical column ordering |
| Date: | 2014-12-10 05:17:33 |
| Message-ID: | 4375.1418188653@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2014-12-10 05:47:54 | Re: inherit support for foreign tables |
| Previous Message | Tom Lane | 2014-12-10 05:11:42 | Re: logical column ordering |