Re: performance of SELECT * much faster than SELECT <colname> with large offset

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marc Slemko <marcs(at)znep(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: performance of SELECT * much faster than SELECT <colname> with large offset
Date: 2014-10-03 08:40:04
Message-ID: CABRT9RC5rqbVYpPvJSFGNXVykLv8O9iG7--qdnxdQWNLwiaNug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Oct 3, 2014 at 5:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marc Slemko <marcs(at)znep(dot)com> writes:
>> I ran into this oddity lately that goes against everything I thought I
>> understood and was wondering if anyone had any insight.
>
> SELECT * avoids a projection step ... see ExecAssignScanProjectionInfo.

It would be cool if OFFSET could somehow signal the child nodes "don't
bother constructing the actual tuple". Not sure if that could work in
more complex queries. But this is just one of many performance
problems with large OFFSETs.

Of course you can always work around this using a subquery...
select description from (
select * from ccrimes offset 5140000 limit 1
) subq;

But most of the time it's better to use scalable paging techniques:
http://use-the-index-luke.com/sql/partial-results/fetch-next-page

Regards,
Marti

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Roberto Grandi 2014-10-03 08:55:04 Planning for Scalability
Previous Message Tom Lane 2014-10-03 02:39:37 Re: performance of SELECT * much faster than SELECT <colname> with large offset