Re: shouldn't postgres know the numer of rows in a (sorted) result-set before returning the first row?

["Thies C. Arntzen" <thies@xxxxxxxxxx>]

Am 16.11.2005 um 14:49 schrieb Martijn van Oosterhout:

i understand that postgres has to read every row from the heap to make 

sure that they are all still valid and count. but from my understanding 

query (a) would have something like an uncorrected count (somewhere 

internally) for the whole query as it has to performed an "order by" on 

the result-set before returning the first row.

Not if you have an index on "found_time". In that case it can return

the top 50 without even looking at most of the table. That's what

indexes are for. The only estimate it has is the one in EXPLAIN, and it

can find that without running the query at all.

hey martijn,

my question is more in the line of

http://archives.postgresql.org/pgsql-hackers/2005-01/msg00247.php

whereby my special case is all about beeing able to provide an [possible inaccuate] count for a query if possible: my understanding is that would be the case if the "where clase" and the "order by" clause have been satisfied from the indices and the only step left is to validate the records in the result by reading them from the heap. 

and -again- i'm not asking for a new feature but i'd like to play with it and am asking for hackers advice;-)

what am i missing?

re, thies