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,
Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
[EMAIL PROTECTED] (Jean-Luc Lachance) writes:
That's one of the draw back of MVCC.
I once suggested that the transaction number and other house keeping
info be included in the index, but was told to forget it...
It would solve once
On Fri, 3 Oct 2003, Bruce Momjian wrote:
I have updated the FAQ to be:
In comparison to MySQL or leaner database systems, we are
faster for multiple users, complex queries, and a read/write query
load. MySQL is faster for SELECT queries done by a few users.
Is this
On Fri, Oct 03, 2003 at 02:24:42PM -0600, Rob Nagler wrote:
I've read some posts that says vacuum doesn't lock, but my experience
today indicates the opposite. It seemed that vacuum full analyze
VACUUM doesn't. VACUUM FULL does.
--
Andrew Sullivan 204-4141 Yonge
On Fri, Oct 03, 2003 at 11:49:03PM -0400, Tom Lane wrote:
What if said SELECTs are using the index in question?
That's a good reason to build a new index and, when it's done, drop
the old one. It still prevents writes, of course.
A
--
Andrew Sullivan 204-4141
On Sat, Oct 04, 2003 at 12:29:55AM +0100, Matt Clark wrote:
My real world experience on a *very* heavily updated OLTP type DB, following
advice from this list (thanks guys!), is that there is essentially zero cost
to going ahead and vacuuming as often as you feel like it. Go crazy, and
speed
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
Tom Lane kirjutas L, 04.10.2003 kell 19:07:
Hannu Krosing [EMAIL PROTECTED] writes:
Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
A while back I outlined how this would have to be done, and for it to
be done efficiently, it would be anything BUT simple.
Could this be made a
Hannu Krosing [EMAIL PROTECTED] writes:
The point I was trying to make was that faster count(*)'s is just a side
effect. If we could (conditionally) keep visibility info in indexes,
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are sufficient reason why
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
The point I was trying to make was that faster count(*)'s is just a side
effect. If we could (conditionally) keep visibility info in indexes,
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are
13 matches
Mail list logo
