On 26/05/15 11:59, CK Tan wrote:
It has to do with the implementation of slot_getattr, which tries to do
the deform on-demand lazily.
if you do select a,b,c, the execution would do slot_getattr(1) and
deform a, and then slot_getattr(2) which reparse the tuple to deform b,
and finally slot_getattr(3), which parse the tuple yet again to deform c.
Where as if you do select c, b, a, it would do slot_getattr(3) to deform
c, and in the process deform a and b in one pass. Subsequent calls to
slot_getattr 1 and 2 would find the attribute ready and available, and
return it (without parsing the tuple again).
If this was the case, changing column order would lead to performance
increase, not decrease as reported.
My guess would be same as Amits, it's most likely the additional
projection step.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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
