Re: Order of columns in query is important?!
От | CK Tan |
---|---|
Тема | Re: Order of columns in query is important?! |
Дата | |
Msg-id | CAJNt7=YjzSLUXB1bgV4yDacXvAfUtSTanfniLgygePoAJW1x=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Order of columns in query is important?! (Petr Jelinek <petr@2ndquadrant.com>) |
Список | pgsql-hackers |
<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>
В списке pgsql-hackers по дате отправления: