From: | CK Tan <cktan(at)vitessedata(dot)com> |
---|---|
To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | "Colin 't Hart" <colin(at)sharpheart(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Order of columns in query is important?! |
Date: | 2015-05-26 10:19:20 |
Message-ID: | CAJNt7=YjzSLUXB1bgV4yDacXvAfUtSTanfniLgygePoAJW1x=Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
You're right. I misread the problem description.
On Tue, May 26, 2015 at 3:13 AM, Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-05-26 10:32:08 | Re: Order of columns in query is important?! |
Previous Message | Petr Jelinek | 2015-05-26 10:13:06 | Re: Order of columns in query is important?! |