Re: VACUUM delay (was Re: What's planned for 7.5?)

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: VACUUM delay (was Re: What's planned for 7.5?)
Дата
Msg-id 400BDD99.6050405@Yahoo.com
обсуждение исходный текст
Ответ на Re: VACUUM delay (was Re: What's planned for 7.5?)  ("Stephen" <jleelim@xxxxxxx.com>)
Ответы Re: VACUUM delay (was Re: What's planned for 7.5?)  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список pgsql-hackers
Stephen wrote:

> The vacuum delay patch is not the ideal solution but it worked like a charm
> on my servers. I really need the vacuum delay patch or a better solution in
> 7.5. I'm getting millions of requests a month and running VACUUM without the
> patch makes PostgreSQL useless for many consecutive hours. Not quite the
> 24/7 system I was hopping for. :-(
> 
> Unfortunately, it's rather difficult to patch so many machines as my entire
> system runs on Redhat RPMs. I'm really hopping to see a solution to this
> VACUUM problem in 7.5. I've been waiting for this fix for over 3 years and
> now it's almost there.
> 
> Will this problem get addressed in the not so official TODO list?

Well, I had a few different "versions" of vacuum delay stuff out as 
patches, together with ARC and the beginnings of the background writer. 
Instead of getting some numbers on those, the whole discussion got stuck 
in differences about how we actually let the background writer tell the 
kernel "do something" ... the whole sync(), fsync(), fdatasync(), 
fadvise() discussion.

I don't have the time to make enough different attempts to find the one 
that pleases all. My argument still is that all this IO throttling and 
IO optimizing is mainly needed for dedicated servers, because I think 
that if you still run multiple services on one box you're not really in 
trouble yet. So in the first round a configurable sync() approach would 
do. So far nobody even agreed to that.

I currently have better to do. We do not have a big IO problem, we have 
other problems, and I spend my time on solving them. If someone wants to 
pick up the IO throttle problem, I am allways here to help, but I will 
not waste my time with making patches nobody even gives a try.

> 
> Thanks and keep up the good work!

Sorry for the venting, but I needed that out.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



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

Предыдущее
От: Shachar Shemesh
Дата:
Сообщение: Getting the results columns before execution
Следующее
От: Darko Prenosil
Дата:
Сообщение: Re: Getting the results columns before execution