-----Original Message----- From: Doug McNaught [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 11:30 AM To: Dann Corbit Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] Suggestion for optimization
"Dann Corbit" <[EMAIL PROTECTED]> writes: > It would be nice if total table cardinality could be maintained live. > So (after the initial vacuum) we update the cardinality for each table > in the system table (or perhaps add an entry to the table itself). > There are two reasons why this is an important optimization. Firstly, > it is a psychological benefit for both benchmarks and customers when > doing a select count(*) from <tablename>. This is something that pops > up all the time in benchmarks and customers do it too, in order to get a > feel for speed. By storing the current number and incrementing for > every insert and decrementing for every delete, the count(*) case with > no where clause can return the value instantly. How would this work with MVCC? >> Whenever a commit occurs, the pending inserts are totaled into the sum and the pending deletes are subtracted. It can be a list in memory or whatever. Maybe you are referring to the old (expired) rows begin stored until vacuum? Perhaps I really don't understand your question or the issues involved. Why does MVCC complicate issues? << ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
