You're right. I misread the problem description. On Tue, May 26, 2015 at 3:13 AM, Petr Jelinek <p...@2ndquadrant.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 >
