Date: Sat, 19 Apr 2003 23:28:52 -0700
From: Kevin Brown <kevin@sysexperts.com>
To: pgsql-performance@postgresql.org
Subject: Re: [SQL] Yet Another (Simple) Case of Index not used
Message-ID: <20030420062852.GK1847@filer>
Mail-Followup-To: Kevin Brown <kevin@sysexperts.com>,
	pgsql-performance@postgresql.org
References: <EKEBJNAJDPKJBDFGJNIJAENMDBAA.denis@next2me.com>
	<200304090918.45275.josh@agliodbs.com>
	<20030419130146.GI1847@filer> <21955.1050767928@sss.pgh.pa.us>
	<20030420011336.GJ1847@filer> <24735.1050809664@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <24735.1050809664@sss.pgh.pa.us>
User-Agent: Mutt/1.4i
Organization: Frobozzco International

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