Re: [SQL] Yet Another (Simple) Case of Index not used
От | Kevin Brown |
---|---|
Тема | Re: [SQL] Yet Another (Simple) Case of Index not used |
Дата | |
Msg-id | 20030420062852.GK1847@filer обсуждение исходный текст |
Ответ на | Re: [SQL] Yet Another (Simple) Case of Index not used (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [SQL] Yet Another (Simple) Case of Index not used
Re: [SQL] Yet Another (Simple) Case of Index not used |
Список | pgsql-performance |
Tom Lane wrote: > Kevin Brown <kevin@sysexperts.com> writes: > > Tom Lane wrote: > >> You missed the point of Josh's comment: in an MVCC system, the correct > >> COUNT() varies depending on which transaction is asking. Therefore it > >> is not possible for a centrally maintained row counter to give accurate > >> results to everybody, no matter how cheap it is to maintain. > > > Hmm...true...but only if you really implement it as a faithful copy of > > the trigger-based method. > > [ instead have transactions save up net deltas to apply at commit ] > > Good try, but it doesn't solve the problem. SERIALIZABLE transactions > should not see deltas applied by any transaction that commits after > they start. READ COMMITTED transactions can see such deltas --- but not > deltas applied since the start of their current statement. (And there > could be several different "current statements" with different snapshots > in progress in a single READ COMMITTED transaction.) This is why I suspect the best way to manage this would be to manage the counter itself using the MVCC mechanism (that is, you treat the shared counter as a row in a table just like any other and, in fact, it might be most beneficial for it to actually be exactly that), which handles the visibility problem automatically. But I don't know how much contention there would be as a result. > Of course you can dodge lots of this overhead if you're willing to > accept approximate answers. But I don't believe that central counters > are useful in an exact-MVCC-semantics system. No, but an MVCC-managed counter would be useful in such a system, wouldn't it? Or am I missing something there, too (the deltas themselves would be managed as described, and would be applied as described)? So: how much contention would there be if the counter were managed in exactly the same way as any row of a table is managed? Because I'm not terribly familiar with how PG manages MVCC (pointers to documentation on it welcomed) I can't answer that question myself. -- Kevin Brown kevin@sysexperts.com
В списке pgsql-performance по дате отправления: