Re: Speed with offset clause

>
> Hmm, I can't do this, i'm afraid. Or it would be rather difficult
>
> My query is executed through a webpage (link to the page in a
> navigation bar)
> I do not know how many records there are (data is changing, and
> currently is 600k records)
>
> The only thing I could do, is doing this in a function where I first
> get the page, and then decide whether to use the normal sort order or
> the reversed order
> That would put my weak point right in the middle, which is not that
> bad, but I would like to find an easier way, if that is possible
>
> Huge memory would help ?
>
> On 24 Jun 2005, at 20:54, hubert depesz lubaczewski wrote:
>
>> On 6/24/05, Yves Vindevogel <yves(dot)vindevogel(at)implements(dot)be> wrote:
>>> So, when I want the last page, which is: 600k / 25 = page 24000 - 1 =
>>> 23999, I issue the offset of 23999 * 25
>>
>> improving this is hard, but not impossible.
>> if you have right index created, try to reverse the order and fetch
>> first adverts, and then resort it (just the 25 adverts) in correct
>> order.
>> it will be faster.
>>
>> depesz
>>
>>
> Met vriendelijke groeten,
> Bien à vous,
> Kind regards,
>
> Yves Vindevogel
> Implements
>

I just ran this query

select p.* from tblPrintjobs p , (select oid from tblPrintjobs limit 25
offset 622825) as subset where p.oid = subset.oid

And it seems to be a bit faster than without the subselect, probably
because I'm only getting one column.
The speed gain is not that high though

On 24 Jun 2005, at 22:19, Yves Vindevogel wrote:

>>
>> Hmm, I can't do this, i'm afraid. Or it would be rather difficult
>>
>> My query is executed through a webpage (link to the page in a
>> navigation bar)
>> I do not know how many records there are (data is changing, and
>> currently is 600k records)
>>
>> The only thing I could do, is doing this in a function where I first
>> get the page, and then decide whether to use the normal sort order or
>> the reversed order
>> That would put my weak point right in the middle, which is not that
>> bad, but I would like to find an easier way, if that is possible
>>
>> Huge memory would help ?
>>
>> On 24 Jun 2005, at 20:54, hubert depesz lubaczewski wrote:
>>
>>> On 6/24/05, Yves Vindevogel <yves(dot)vindevogel(at)implements(dot)be> wrote:
>>>> So, when I want the last page, which is: 600k / 25 = page 24000 - 1
>>>> =
>>>> 23999, I issue the offset of 23999 * 25
>>>
>>> improving this is hard, but not impossible.
>>> if you have right index created, try to reverse the order and fetch
>>> first adverts, and then resort it (just the 25 adverts) in correct
>>> order.
>>> it will be faster.
>>>
>>> depesz
>>>
>>>
>> Met vriendelijke groeten,
>> Bien à vous,
>> Kind regards,
>>
>> Yves Vindevogel
>> Implements
>>
> <Pasted Graphic 2.tiff>
>>
>> Mail: yves(dot)vindevogel(at)implements(dot)be - Mobile: +32 (478) 80 82 91
>>
>> Kempische Steenweg 206 - 3500 Hasselt - Tel-Fax: +32 (11) 43 55 76
>>
>> Web: http://www.implements.be
>>
>> First they ignore you. Then they laugh at you. Then they fight you.
>> Then you win.
>> Mahatma Ghandi.
>>
>>
> Met vriendelijke groeten,
> Bien à vous,
> Kind regards,
>
> Yves Vindevogel
> Implements
>
> <Pasted Graphic 2.tiff>
>
> Mail: yves(dot)vindevogel(at)implements(dot)be - Mobile: +32 (478) 80 82 91
>
> Kempische Steenweg 206 - 3500 Hasselt - Tel-Fax: +32 (11) 43 55 76
>
> Web: http://www.implements.be
>
> First they ignore you. Then they laugh at you. Then they fight you.
> Then you win.
> Mahatma Ghandi.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo(at)postgresql(dot)org
>
Met vriendelijke groeten,
Bien à vous,
Kind regards,

Yves Vindevogel
Implements

> I just ran this query
>
> select p.* from tblPrintjobs p , (select oid from tblPrintjobs limit 25
> offset 622825) as subset where p.oid = subset.oid
>

I'm just curious here, from a social point of view. How often do you think
someone will paginate over say 300K rows in steps of 25 ?
The way I see things, pagination is only meant for humans. If someone
really looks at 300K rows then it's really cheaper and makes more sense to
download them/import into spreadsheet program instead of clicking next
12.000 times.
If it's not intended for humans then there's better ways of doing this.

Regards,
--
Radu-Adrian Popescu
CSA, DBA, Developer
Aldrapay MD
Aldratech Ltd.
+40213212243