Re: Slow count(*) again...

From: Neil Whelchel <neil(dot)whelchel(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow count(*) again...
Date: 2010-10-12 22:33:33
Message-ID: 201010121533.34047.neil.whelchel@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Tuesday 12 October 2010 08:39:19 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.
>
> -Dan

I would like to know the details of what was going on that caused your
problem. I have been using XFS for over 9 years, and it has never caused any
trouble at all in a production environment. Sure, I had many problems with it
on the test bench, but in most cases the issues were very clear and easy to
avoid in production. There were some (older) XFS tools that caused some
problems, but that is in the past, and as time goes on, it seems take less and
less planning to make it work properly.
-Neil-

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Darren Duncan 2010-10-12 22:34:42 Re: SQL command to edit postgresql.conf, with comments
Previous Message Mladen Gogala 2010-10-12 22:30:38 Re: Slow count(*) again...

Browse pgsql-performance by date

  From Date Subject
Next Message Neil Whelchel 2010-10-12 23:19:33 Re: Slow count(*) again...
Previous Message Mladen Gogala 2010-10-12 22:30:38 Re: Slow count(*) again...