Re: Seqscan in MAX(index_column)
От | Bruce Momjian |
---|---|
Тема | Re: Seqscan in MAX(index_column) |
Дата | |
Msg-id | 200309050428.h854SPk03147@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Seqscan in MAX(index_column) (Christopher Browne <cbbrowne@acm.org>) |
Ответы |
Re: Seqscan in MAX(index_column)
|
Список | pgsql-hackers |
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: