From: | Kevin Brown <kevin(at)sysexperts(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [SQL] Yet Another (Simple) Case of Index not used |
Date: | 2003-04-20 06:28:52 |
Message-ID: | 20030420062852.GK1847@filer |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance pgsql-sql |
Tom Lane wrote:
> Kevin Brown <kevin(at)sysexperts(dot)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(at)sysexperts(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2003-04-20 10:07:53 | Re: [SQL] Yet Another (Simple) Case of Index not used |
Previous Message | Joe Conway | 2003-04-20 04:30:03 | Re: stddev returns 0 when there is one row |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-04-20 06:56:56 | Re: [PERFORM] Foreign key performance |
Previous Message | Tom Lane | 2003-04-20 03:34:24 | Re: [SQL] Yet Another (Simple) Case of Index not used |
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2003-04-20 10:07:53 | Re: [SQL] Yet Another (Simple) Case of Index not used |
Previous Message | Tom Lane | 2003-04-20 03:34:24 | Re: [SQL] Yet Another (Simple) Case of Index not used |