Re: *sigh*

*growl* - it sounds like the business...and I was all set to code it,
however after delving into Pg's aggregation structure a bit, it suffers
a fatal flaw :

There appears to be no way to avoid visiting every row when defining an
aggregate (even if you do nothing on each one) -- which defeats the
whole point of my suggestion (i.e avoiding the visit to every row)

To make the original idea work requires amending the definition of Pg
aggregates to introduce "fake" aggregates that don't actually get
evaulated for every row. At this point I am not sure if this sort of
modification is possible or reasonable - others who know feel free to
chip in :-)

regards

Mark

Randolf Richardson wrote:

>"markir(at)paradise(dot)net(dot)nz (Mark Kirkwood)" wrote in
>comp.databases.postgresql.hackers:
>
>[sNip]
>
>
>>How about:
>>
>>Implement a function "estimated_count" that can be used instead of
>>"count". It could use something like the algorithm in
>>src/backend/commands/analyze.c to get a reasonably accurate psuedo count
>>quickly.
>>
>>The advantage of this approach is that "count" still means (exact)count
>>(for your xact snapshot anyway). Then the situation becomes:
>>
>>Want a fast count? - use estimated_count(*)
>>Want an exact count - use count(*)
>>
>>
>
> I think this is an excellent solution.
>
>
>