Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id 23D0E1337B88
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue, 12 Oct 2010 00:42:54 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 59614-07
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue, 12 Oct 2010 03:42:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from kuva.firstlight.net (kuva.firstlight.net [216.86.201.22])
	by mail.postgresql.org (Postfix) with ESMTP id 7093D1337BB1
	for <pgsql-performance@postgresql.org>;
	Tue, 12 Oct 2010 00:42:46 -0300 (ADT)
Received: from carbon.firstlight.net (unknown [66.51.204.93])
	by kuva.firstlight.net (Postfix) with ESMTPA id 8896F271D3
	for <pgsql-performance@postgresql.org>;
	Mon, 11 Oct 2010 20:42:45 -0700 (PDT)
From: Neil Whelchel <neil.whelchel@gmail.com>
Organization: Go-Automation
To: pgsql-performance@postgresql.org
Subject: Re: Slow count(*) again...
Date: Mon, 11 Oct 2010 20:42:42 -0700
User-Agent: KMail/1.13.5 (Linux/2.6.35.5; KDE/4.5.1; i686; ; )
References: <201010091626.18636.neil.whelchel@gmail.com>
	<90E30938-1E5E-4DCA-A1FB-AEECEB76A70D@richrelevance.com>
	<4CB3C6B2.8050501@vmsinfo.com>
In-Reply-To: <4CB3C6B2.8050501@vmsinfo.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201010112042.43504.neil.whelchel@gmail.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9
X-Spam-Level: 
X-Archive-Number: 201010/127
X-Sequence-Number: 40546

On Monday 11 October 2010 19:23:46 Mladen Gogala wrote:
>   On 10/11/2010 10:02 PM, Scott Carey wrote:
> > Did you tune the linux FS read-ahead first?  You can get large gains by
> > doing that if you are on ext3. blockdev --setra 2048<device>
> 
> Actually, I have blockdev --setra 32768
> 
> > would give you a 1MB read-ahead.  Also, consider XFS and its built-in
> > defragmentation.  I have found that a longer lived postgres DB will get
> > extreme file fragmentation over time and sequential scans end up mostly
> > random.  On-line file defrag helps tremendously.
> 
> I agree, but I am afraid that after the demise of SGI, XFS isn't being
> developed. The company adopted the policy of using only the plain
> vanilla Ext3, which is unfortunate, but I can't do much about it. There
> is a lesson to be learned from the story of ReiserFS. I am aware of the
> fact that Ext3 is rather basic, block oriented file system which doesn't
> perform well when compared to HPFS, VxFS or JFS2 and has no notion of
> extents, but I believe that I am stuck with it, until the advent of
> Ext4. BTW, there is no defragmenter for Ext4, not even on Ubuntu, which
> is rather bleeding edge distribution.

When it comes to a database that has many modifications to its tables, it 
seems that XFS pulls way ahead of other filesystems (likely) because of its 
on-line defragmentation among other reasons. I am not sure that XFS is not 
(properly) maintained. The people at xfs.org seem to be making steady 
progress, and high quality updates. I have been using it for some time now (9+ 
years), and as it is, it does everything I need it to do, and it is very 
reliable. I really can't see anything changing in the next few years that 
would effect its usability as a filesystem for Postgres, so until something 
proves to be better, I can't understand why you wouldn't want to use it, 
maintained or not.
-Neil-