Re: large table vacuum issues

Поиск
Список
Период
Сортировка
От Bill Moran
Тема Re: large table vacuum issues
Дата
Msg-id 20080105081849.eb6fa46a.wmoran@potentialtech.com
обсуждение исходный текст
Ответ на Re: large table vacuum issues  ("Ed L." <pgsql@bluepolka.net>)
Список pgsql-general
"Ed L." <pgsql@bluepolka.net> wrote:
>
> On Friday 04 January 2008 6:21 pm, Scott Marlowe wrote:
> > On Jan 4, 2008 6:38 PM, Ed L. <pgsql@bluepolka.net> wrote:
> > > We need some advice on how to handle some large table
> > > autovacuum issues.  One of our 8.1.2
> >
> > First of all, update your 8.1 install to 8.1.10.  Failing to
> > keep up with bug fixes is negligent.  who knows, you might be
> > getting bitten by a bug that was fixed between 8.1.2 and
> > 8.1.10
>
> Could be.  But like you said, who knows.  In some environments,
> downtime for upgrading costs money (and more), too, sometimes
> even enough to make it "negligent" to take downtime to keep up
> with bug fixes (and of course, the new bugs) which may or may
> not be a factor at hand.

Upgrades along the 8.1.x branch take something on the order of
5 minutes (if you're meticulous and serialize the process).

If you haven't set yourself up so you can schedule 5 minutes of
downtime once a month or so, then the negligence occurred much
earlier than at the failure to upgrade.

> While the time required to restart a
> DB may be neglible, there are often upstream/downstream
> dependencies that greatly expand the actual downtime for the
> customer.

Like what?  The point to the double-dot branch is that upgrades
don't affect dependencies.

> How much would downtime need to cost before you
> thought it negligent to upgrade immediately?  It's a tradeoff,
> not well-supported by simple pronouncements, one the customer
> and provider are best qualified to make.

Not really.  Unscheduled downtime is _always_ more expensive than
scheduled downtime.  Scheduled downtime isn't going to put you in
breach of contract if you've got an uptime guarantee.

If you're really in a situation where you need 100% uptime, then
you're still negligent for not having something like Slony to allow
you to switch production to another server so you can alternate
maintenance between the two.

This is something along the RAID 5 argument, no matter how you argue
it, it's a bad idea.  If you claim you can't afford to buy more hardware,
then you made a mistake in pricing out your product to your client.

--
Bill Moran
http://www.potentialtech.com

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Need efficient way to do comparison with NULL as an option
Следующее
От: Clodoaldo
Дата:
Сообщение: Re: Performance problem. Could it be related to 8.3-beta4?