Re: Slow count(*) again...

Поиск
Список
Период
Сортировка
От Neil Whelchel
Тема Re: Slow count(*) again...
Дата
Msg-id 201010112042.43504.neil.whelchel@gmail.com
обсуждение исходный текст
Ответ на Re: Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Список 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-

В списке pgsql-performance по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: How does PG know if data is in memory?
Следующее
От: Samuel Gendler
Дата:
Сообщение: Re: Slow count(*) again...