Re: Frequently updated tables

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Frequently updated tables
Дата
Msg-id 1086805587.23855.34.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Frequently updated tables  (pgsql@mohawksoft.com)
Список pgsql-hackers
On Wed, 2004-06-09 at 11:41, pgsql@mohawksoft.com wrote:
> > On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
> >> >I love PG, I've been using it since version 6x, and it has gotten
> >> >fantastic over the years, and in many cases, I would choose it over
> >> >Oracle, but for systems that need frequent updates, I have a lot of
> >> >concerns.
> >>
> >> ...that's the price you pay for concurrency man...
> >
> > Also he said that the problem was solved with enough lazy VACUUM
> > scheduling.  I don't understand why he doesn't want to use that
> > solution.
> >
> 
> Sigh, because vacuums take away from performance. Imagine a table that has
> to be updated on the order of a few thousand times a minute. Think about
> the drop in performance during the vacuum.
> 
> On a one row table, vacuum is not so bad, but try some benchmarks on a
> table with a goodly number of rows.

Several points:

All databases pay to clean up the mess they've made, so to speak.  In
PostgreSQL you get to choose when, instead of always paying the price at
the end of transaction.

Lazy vacuum does not impact performance nearly as much as the old full
vacuum.  With the sleep / delay patch that's been passed around on
hackers its impact is virtually zero on the rest of the database

Properly setup fsm settings, pg_autovacuum deamon, and an installation
of the sleep / delay patch mentioned aobve makes this a non-issue.



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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Frequently updated tables
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: thread safety tests