Re: reindex/vacuum locking/performance?

Поиск
Список
Период
Сортировка
От Jeff
Тема Re: reindex/vacuum locking/performance?
Дата
Msg-id Pine.BSF.4.44.0310060757330.52159-100000@torgo.978.org
обсуждение исходный текст
Ответ на Re: reindex/vacuum locking/performance?  (Neil Conway <neilc@samurai.com>)
Ответы Re: reindex/vacuum locking/performance?  (Andrew Sullivan <andrew@libertyrms.info>)
Re: reindex/vacuum locking/performance?  (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>)
Список pgsql-performance
On Sun, 5 Oct 2003, Neil Conway wrote:

>
> > I don't know any portable way to do that :-(
>
> For the non-portable way of doing this, are you referring to O_DIRECT?
>
> Even if it isn't available everywhere, it might be worth considering
> this at least for the platforms on which it is supported.
>

I strongly agree here only if we can prove there is a benefit.
I think it would be silly of us if some OS supported SnazzyFeatureC that
was able to speed up PG by a large percentage (hopefully, in a rather
non-invasive way in the code).  But, I do see the problem here with bloat
and PG being radically different platform to platform.  I suppose we could
dictate that at least N os's had to have it.. or perhaps supply it has
contrib/ patches.... Something to think about.

I'd be interested in tinkering with this, but I'm more interested at the
moment of why (with proof, not antecdotal) Solaris is so much slower than
Linux and what we cna do about this.  We're looking to move a rather large
Informix db to PG and ops has reservations about ditching Sun hardware.

--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/



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

Предыдущее
От: Stef
Дата:
Сообщение: Re: Postgres low end processing.
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: reindex/vacuum locking/performance?