*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:

"[EMAIL PROTECTED] (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.






---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to