From: Scott Carey <scott@richrelevance.com>
To: Dan Harris <fbsd@drivefaster.net>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Slow count(*) again...
Date: Tue, 12 Oct 2010 09:44:02 -0700
Message-ID: <8BE535FE-F9DB-4CBC-A932-EB4F07905698@richrelevance.com> (raw)
In-Reply-To: <4CB48127.6090200@drivefaster.net>
References: <201010091626.18636.neil.whelchel@gmail.com>
<4CB11CC7.8070300@vmsinfo.com>
<4CB167CA.9070109@postnewspapers.com.au>
<4CB1F46E.80205@vmsinfo.com>
<90E30938-1E5E-4DCA-A1FB-AEECEB76A70D@richrelevance.com>
<4CB48127.6090200@drivefaster.net>
On Oct 12, 2010, at 8:39 AM, Dan Harris wrote:
> On 10/11/10 8:02 PM, Scott Carey wrote:
>> 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.
>>
> We just had a corrupt table caused by an XFS online defrag. I'm scared
> to use this again while the db is live. Has anyone else found this to
> be safe? But, I can vouch for the fragmentation issue, it happens very
> quickly in our system.
>
What version? I'm using the latest CentoOS extras build.
We've been doing online defrag for a while now on a very busy database with > 8TB of data. Not that that means there are no bugs...
It is a relatively simple thing in xfs -- it writes a new file to temp in a way that allocates contiguous space if available, then if the file has not been modified since it was re-written it is essentially moved on top of the other one. This should be safe provided the journaling and storage is safe, etc.
> -Dan
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: scott@richrelevance.com, fbsd@drivefaster.net
Subject: Re: Slow count(*) again...
In-Reply-To: <8BE535FE-F9DB-4CBC-A932-EB4F07905698@richrelevance.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox