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

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