*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@paradise.net.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.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase