This may be a long shot but you could try a view that has one field and
that field would be the count(*) of the table i don't think this would add
to much overhead.
Just a thought
Darren
Darren Ferguson
Software Engineer
Openband
On Wed, 19 Dec 2001, Martijn van Oosterhout wrote:
> On Tue, Dec 18, 2001 at 09:19:46PM -0700, Mitch Vincent wrote:
> > > I gather the reason you don't actually run the whole query is because the
> > > resultset would be too large? But you still want the database to work out
> > > exactly how many there are.
> >
> > Not really because it's too large but because there isn't a need.. Imagine
> > your favorite search engine, you search and the results are displayed "X
> > Matches, displaying matches 1 to 10"... Same thing here -- at least that's
> > what my need was... The query executed could get really stout (there were
> > over 60 searchable fields across a variety of tables with hundreds of
> > thousands of records in some) so executing the count() query, then the other
> > certainly added the overhead... A cursor wasn't usable in this situation
> > because the user could chose to search once, having only ten results
> > displayed of 10,000 and leave the page (thus leaving me with an open
> > cursor).....
>
> I'd be tempted to simply limit to 100 or so and if you get over 100, say
> "matched over 100 documents". As for the cursor, I don't think google
> remembers your results while switching between pages. If you switch back and
> forth between pages I'm pretty sure the results change from time to time.
>
> If you think about the number is servers they have, caching query results
> would be almost as complicated as the searching itself.
> --
> Martijn van Oosterhout <kleptog@svana.org>
> http://svana.org/kleptog/
> > Terrorists can only take my life. Only my government can take my freedom.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>