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 03:42:42
Message-ID: 201010112042.43504.neil.whelchel@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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-

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Samuel Gendler 2010-10-12 03:58:45 Re: Slow count(*) again...
Previous Message Hitoshi Harada 2010-10-12 03:08:32 Re: wip: functions median and percentile

Browse pgsql-performance by date

  From Date Subject
Next Message Samuel Gendler 2010-10-12 03:58:45 Re: Slow count(*) again...
Previous Message gnuoytr 2010-10-12 03:11:34 Re: How does PG know if data is in memory?