<div dir="ltr">You're right. I misread the problem description. </div><div class="gmail_extra"><br /><div
class="gmail_quote">OnTue, May 26, 2015 at 3:13 AM, Petr Jelinek <span dir="ltr"><<a
href="mailto:petr@2ndquadrant.com"target="_blank">petr@2ndquadrant.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26/05/15
11:59,CK Tan wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">It has to do with the implementation of slot_getattr, which tries to do<br /> the deform
on-demandlazily.<br /><br /> if you do select a,b,c, the execution would do slot_getattr(1) and<br /> deform a, and
thenslot_getattr(2) which reparse the tuple to deform b,<br /> and finally slot_getattr(3), which parse the tuple yet
againto deform c.<br /><br /> Where as if you do select c, b, a, it would do slot_getattr(3) to deform<br /> c, and in
theprocess deform a and b in one pass. Subsequent calls to<br /> slot_getattr 1 and 2 would find the attribute ready
andavailable, and<br /> return it (without parsing the tuple again).<br /><br /></blockquote><br /></span> If this was
thecase, changing column order would lead to performance increase, not decrease as reported.<br /><br /> My guess would
besame as Amits, it's most likely the additional projection step.<span class="HOEnZb"><font color="#888888"><br /><br
/>-- <br /> Petr Jelinek <a href="http://www.2ndQuadrant.com/"
target="_blank">http://www.2ndQuadrant.com/</a><br/> PostgreSQL Development, 24x7 Support, Training & Services<br
/></font></span></blockquote></div><br/></div>