Re: Frequently updated tables

From: "Scott Marlowe" <smarlowe(at)qwest(dot)net>
To: pgsql(at)mohawksoft(dot)com
Cc: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Mark Kirkwood" <markir(at)coretech(dot)co(dot)nz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Frequently updated tables
Date: 2004-06-09 18:26:27
Message-ID: 1086805587.23855.34.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2004-06-09 at 11:41, pgsql(at)mohawksoft(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2004-06-09 18:27:08 Re: thread safety tests
Previous Message Joshua D. Drake 2004-06-09 18:16:17 Re: Frequently updated tables