Re: Frequently updated tables - Mailing list pgsql-hackers

From Scott Marlowe
Subject Re: Frequently updated tables
Date
Msg-id 1086805587.23855.34.camel@localhost.localdomain
Whole thread Raw
In response to Re: Frequently updated tables  (pgsql@mohawksoft.com)
List 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 by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Frequently updated tables
Next
From: Jan Wieck
Date:
Subject: Re: thread safety tests