Kevin Brown wrote:
>
>No, but an MVCC-managed counter would be useful in such a system,
>wouldn't it? Or am I missing something there, too (the deltas
>themselves would be managed as described, and would be applied as
>described)?
>
>So: how much contention would there be if the counter were managed in
>exactly the same way as any row of a table is managed? Because I'm
>not terribly familiar with how PG manages MVCC (pointers to
>documentation on it welcomed) I can't answer that question myself.
>
>
>
It looks to me that a "row number -1" really would solve this problem.
I think a row counter on each table would be even useful for some kind
of auto-vacuum mechanism, that could be triggered if pg_class.reltuples
deviates too far from the real row count. Observing this mailing list,
missing or outdated statistics still seem to be a major source of
performance degradation. We all know these 1000 row estimates from
EXPLAIN, don't we? A default vacuum strategy for pgsql newbies should
solve a lot of those problems, preventing a lot of "pgsql is slow" threads.
Regards,
Andreas
