Re: count(*) slow on large tables

Bruce Momjian wrote:
> OK, I beefed up the TODO:
>
> * Use a fixed row count and a +/- count with MVCC visibility rules
> to allow fast COUNT(*) queries with no WHERE clause(?)
>
> I can always give the details if someone asks. It doesn't seem complex
> enough for a separate TODO.detail item.

May I propose alternate approach for this optimisation?

- Postgresql allows to maintain user defined variables in shared memory.
- These variables obey transactions but do not get written to disk at all.
- There should be a facility to detect whether such a variable is initialized or
not.

How it will help? This is in addition to trigger proposal that came up earlier.
With triggers it's not possible to make values visible across backends unless
trigger updates a table, which eventually leads to vacuum/dead tuples problem.

1. User creates a trigger to check updates/inserts for certain conditions.
2. It updates the count as and when required.
3. If the trigger detects the count is not initialized, it would issue the same
query first time. There is no avoiding this issue.

Besides providing facility of resident variables could be used imaginatively as
well.

Does this make sense? IMO this is more generalised approach over all.

Just a thought.

Shridhar