Message-ID: <55644732.8050506@2ndquadrant.com>
Date: Tue, 26 May 2015 12:13:06 +0200
From: Petr Jelinek <petr@2ndquadrant.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: CK Tan <cktan@vitessedata.com>, Colin 't Hart <colin@sharpheart.org>
CC: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
 Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Subject: Re: Order of columns in query is important?!
References: 
 <CAMon-aReV3F4Kn8cN3OhJPe-U1ACkkzzDdOwgtR29yPaA3TmZQ@mail.gmail.com>
 <CAJNt7=bn3KwQ0q8yE-3LfTsTMAQSE7kODV=DC0rx33-nHhN5sw@mail.gmail.com>
In-Reply-To: 
 <CAJNt7=bn3KwQ0q8yE-3LfTsTMAQSE7kODV=DC0rx33-nHhN5sw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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