Christopher Browne wrote: > Wouldn't this more or less be the same thing as having a trigger that > does, upon each insert/delete "update pg_counts set count = count + 1 > where reltable = 45232;"? (... where 1 would be -1 for deletes, and where > 45232 is the OID of the table...) > > Technically, it seems _feasible_, albeit with the problem that it > turns pg_counts into a pretty horrid bottleneck. If lots of backends > are updating that table, then row 45232 in pg_counts becomes > troublesome because all those processes have to serialize around > updating it. > > And if I have tables where I insert lots of data, but couldn't care > less how many rows they have, this effort is wasted. > > When I was curious as to how COUNT might be maintained, I was pretty > sure that this wouldn't be the preferred method...
See my later idea of the trigger doing +/-1 rather than locking the value during the transaction. If we don't do it this way, I can't think of another way that would honor MVCC visibility. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
