To: Kevin Brown <kevin@sysexperts.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: [SQL] Yet Another (Simple) Case of Index not used 
In-reply-to: <20030421004630.GL1847@filer> 
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>
	<20030420062852.GK1847@filer> <26961.1050852092@sss.pgh.pa.us>
	<20030421004630.GL1847@filer>
Comments: In-reply-to Kevin Brown <kevin@sysexperts.com>
	message dated "Sun, 20 Apr 2003 17:46:30 -0700"
Date: Sun, 20 Apr 2003 21:53:20 -0400
Message-ID: <21712.1050890000@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Kevin Brown <kevin@sysexperts.com> writes:
> Personally, I'd rather see such development effort go towards more
> beneficial improvements, such as replication, 2PC, SQL/MED, etc. (or
> even improving the efficiency of MVCC, since it was mentioned here as
> a problem! :-).  I consider COUNT(*) without a WHERE clause to be a
> corner case, despite the frequency of questions about it.

Exactly.

> But I don't
> think we should reject a patch to implement fast COUNT(*) just because
> it represents a performance tradeoff, at least if it's GUC-controlled.

Well, this is moot since I see no one offering to provide such a patch.
But performance tradeoffs are only one of the costs involved.  I suspect
any such mechanism would be invasive enough to represent a nontrivial
ongoing maintenance cost, whether anyone uses it or not.  The extent
to which it munges core functionality would have to be a factor in
deciding whether to accept it.  It'd take lots more thought than we've
expended in this thread to get an accurate handle on just what would
be involved...

(BTW, if anyone actually is thinking about this, please make it a
per-table option not a global GUC option.)

			regards, tom lane