Message-ID: <3EA27179.6010307@web.de>
Date: Sun, 20 Apr 2003 12:07:53 +0200
From: Andreas Pflug <Andreas.Pflug@web.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: [SQL] Yet Another (Simple) Case of Index not used
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>
In-Reply-To: <20030420062852.GK1847@filer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kevin Brown wrote:

>
>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.
>
>  
>
It looks to me that a "row number -1" really would solve this problem.

 I think a row counter on each table would be even useful for some kind 
of auto-vacuum mechanism, that could be triggered if pg_class.reltuples 
deviates too far from the real row count. Observing this mailing list, 
missing or outdated statistics still seem to be a major source of 
performance degradation. We all know these 1000 row estimates from 
EXPLAIN, don't we? A default vacuum strategy for pgsql newbies should 
solve a lot of those problems, preventing a lot of "pgsql is slow" threads.

Regards,
Andreas