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
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
Bruce,
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.
Hmmm ...
And for those GUIs, wouldn't it be 97% as good to run an ANALYZE and give the
approximate record counts for large tables?
Interfaces which run a COUNT(*) like that are broken by design. They
fail to consider the table may really be a view which of course could
not be cached with results like
On our message boards each post is a row. The powers that be like to know
how many posts there are total (In addition to 'today')-
select count(*) from posts is how it has been
done on our informix db. With our port to PG I instead select reltuples
pg_class.
We have exactly the same situation,
Bruce Momjian [EMAIL PROTECTED] writes:
We do have a TODO item:
* Consider using MVCC to cache count(*) queries with no WHERE clause
The idea is to cache a recent count of the table, then have
insert/delete add +/- records to the count. A COUNT(*) would get the
main cached record plus
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
... and it would give the wrong answers. Unless the cache is somehow
snapshot-aware, so that it can know which other transactions should be
included in your count.
The cache is an ordinary table, with xid's on every row. I meant it
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
... and it would give the wrong answers. Unless the cache is somehow
snapshot-aware, so that it can know which other transactions should be
included in your count.
The cache is an ordinary table, with xid's on
Bruce Momjian [EMAIL PROTECTED] writes:
It doesn't seem complex enough for a separate TODO.detail item.
I thought it was, if only because it is so easy to think of wrong
implementations.
regards, tom lane
---(end of
Oops! [EMAIL PROTECTED] (Dror Matalon) was seen spray-painting on a wall:
I smell a religious war in the aii:-).
Can you go several days in a row without doing select count(*) on any
of your tables?
I would be more likely, personally, to run VACUUM VERBOSE ANALYZE,
which has useful
On Thu, 2 Oct 2003, Christopher Browne wrote:
I can't imagine why the raw number of tuples in a relation would be
expected to necessarily be terribly useful.
We use stuff like that for reporting queries.
example:
On our message boards each post is a row. The powers that be like to know
how
On Thu, Oct 02, 2003 at 12:46:45 -0700,
Dror Matalon [EMAIL PROTECTED] wrote:
Please keep replies copied to the list.
When would it happen that a tuple be invisible to the current
transaction? Are we talking about permissions?
They could be tuples that were changed by a transaction that
Christopher Browne [EMAIL PROTECTED] writes:
It would be very hairy to implement it correctly, and all this would
cover is the single case of SELECT COUNT(*) FROM SOME_TABLE;
If you had a single WHERE clause attached, you would have to revert to
walking through the tuples looking for the
13 matches
Mail list logo
