Re: Paging through records on the web

Started by K Parkeralmost 26 years ago2 messagesgeneral
Jump to latest
#1K Parker
kparker@eudoramail.com

Where in postgresql you would say

select * from foo limit 20

...

Related question: A typical web search interface
needs a page based browsing system where you
can list the 10 next matches...
I'm thinking of something like :

select * from foo where <some search criteria> and
rownum >= 30 and rownum < 40

Or is this where I should look into using
cursors to access the result set ?

I don't think cursors will work without some
very fancy back-end programming to match up each successive web-page request with
_the same_ process so you have somewhere
to maintain that cursor.

As an alternative, you're almost certainly presenting the records
in sorted order, so you may be able find a unique or almost-unique
set of fields to control the starting record.

The following is from a PHP application that displays a user's login
history in reverse order. '$_init_date' is sent via a hidden variable
when the user presses the MORE submit button at the end of each page:

$max_time_rows = 20;
if ( $_init_date == '' )
{
$qry = "select checktime, status from checkin \
where acct = $_acct \
order by checktime desc limit $max_time_rows";
}
else
{
$qry = "select checktime, status, from checkin \
where acct = $_acct and checktime <= '$_init_date' \
order by checktime desc limit $max_time_rows";
}

Sure, it's theoretically possible that there will be 2 or more
rows with the exact same login or logout time, but it's unlikely,
and the only harm that results is carrying forward the bottom
row or two onto the next page.

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

#2Charles Tassell
ctassell@isn.net
In reply to: K Parker (#1)
Re: Re: Paging through records on the web

Alternatively, you could do your search once, store the results in a table
along with a search id number, and then just SELECT ... FROM search_cache
WHERE searchId = $SearchID LIMIT $X OFFSET $Y That would cut down on the
processing time of a complex search (ie, searching a product database
based on multiple text fields)

I've been meaning to do this for a search system we run here, but haven't
gotten around to it. I'm looking for a guinea pig to see if it's worth the
effort. :) Alternatively, instead of storing the whole result tuple, you
could just store the OID's and do a SELECT fields FROM search_table WHERE
oid IN (SELECT sved_oid FROM search_cache WHERE searchId = $SearchID LIMIT
$X OFFSET $Y) Easier to implement, and probably not too much slower.

Any PostGres gurus out there who could hazard a guess as to what sort of
speed increase you'd get by searching based on one int (like the OID or
search_id) in comparison to one or two text/varchar fields?

At 03:02 PM 6/8/00, K Parker wrote:

Show quoted text

Where in postgresql you would say

select * from foo limit 20

...

Related question: A typical web search interface
needs a page based browsing system where you
can list the 10 next matches...
I'm thinking of something like :

select * from foo where <some search criteria> and
rownum >= 30 and rownum < 40

Or is this where I should look into using
cursors to access the result set ?

I don't think cursors will work without some
very fancy back-end programming to match up each successive web-page
request with
_the same_ process so you have somewhere
to maintain that cursor.

As an alternative, you're almost certainly presenting the records
in sorted order, so you may be able find a unique or almost-unique
set of fields to control the starting record.

The following is from a PHP application that displays a user's login
history in reverse order. '$_init_date' is sent via a hidden variable
when the user presses the MORE submit button at the end of each page:

$max_time_rows = 20;
if ( $_init_date == '' )
{
$qry = "select checktime, status from checkin \
where acct = $_acct \
order by checktime desc limit $max_time_rows";
}
else
{
$qry = "select checktime, status, from checkin \
where acct = $_acct and checktime <= '$_init_date' \
order by checktime desc limit $max_time_rows";
}

Sure, it's theoretically possible that there will be 2 or more
rows with the exact same login or logout time, but it's unlikely,
and the only harm that results is carrying forward the bottom
row or two onto the next page.

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com