Michael Stone wrote:
On Thu, Mar 22, 2007 at 01:30:35PM +0200, [EMAIL PROTECTED] wrote:
approximated count?????
why? who would need it? where you can use it?
Do a google query. Look at the top of the page, where it says "results N
to M of about O". For user interfaces (which is where a lot of this
count(*) stuff comes from) you quite likely don't care about the exact
count...
Right on, Michael.
One of our biggest single problems is this very thing. It's not a Postgres problem specifically, but more
embedded in the idea of a relational database: There are no "job status" or "rough estimate of
results" or "give me part of the answer" features that are critical to many real applications.
In our case (for a variety of reasons, but this one is critical), we actually
can't use Postgres indexing at all -- we wrote an entirely separate indexing
system for our data, one that has the following properties:
1. It can give out "pages" of information (i.e. "rows 50-60") without
rescanning the skipped pages the way "limit/offset" would.
2. It can give accurate estimates of the total rows that will be returned.
3. It can accurately estimate the time it will take.
For our primary business-critical data, Postgres is merely a storage system, not a search
system, because we have to do the "heavy lifting" in our own code. (To be
fair, there is no relational database that can handle our data.)
Many or most web-based search engines face these exact problems.
Craig
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
