Re: Shortcutting too-large offsets?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Shortcutting too-large offsets?
Date: 2011-09-30 18:56:42
Message-ID: 11059.1317409002@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> In principle, yeah, we could make it do that, but it seems like a likely
>> source of maintenance headaches. This example is not exactly compelling
>> enough to make me want to do it. Large OFFSETs are always going to be
>> problematic from a performance standpoint, and the fact that we could
>> short-circuit this one corner case isn't really going to make them much
>> more usable.

> It's not that uncommon of a corner case though; it's one which happens
> all the time in webapps which paginate. People just have to ask for a
> page after the end. It's really a question of how simple the code to
> make the optimization would be; if it would be a 5-line patch, then it's
> worth it; if it would be a 110-line refactor, no.

No, it's really a question of whether it's worth any lines at all,
and I remain unconvinced. If someone asks for the last page, or any
page near the end, it'll take just about the same amount of time as
asking for a page past the end. So any app like this is going to have
sucky performance, and kluging the corner case isn't going to help much.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ben Chobot 2011-09-30 20:15:43 Re: array_except -- Find elements that are not common to both arrays
Previous Message Josh Berkus 2011-09-30 18:44:25 Re: Shortcutting too-large offsets?