From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: pgsql-performance@postgresql.org
Subject: Re: optimizing db for small table with tons of updates
Date: Mon, 3 Apr 2006 11:29:42 -0700
User-Agent: KMail/1.8
Cc: Kenji Morishige <kenjim@juniper.net>
References: <20060403182403.GA12257@juniper.net>
In-Reply-To: <20060403182403.GA12257@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200604031129.42194.josh@agliodbs.com>

Kenji,

> We used to use MySQL for these tools and we never had any issues, but I
> believe it is due to the transactional nature of Postgres that is adding
> an overhead to this problem. =A0

You're correct.

> Are there any table options that enables=20
> the table contents to be maintained in ram only or have delayed writes
> for this particular table?

No.  That's not really the right solution anyway; if you want=20
non-transactional data, why not just use a flat file?  Or Memcached?

Possible solutions:
1) if the data is non-transactional, consider using pgmemcached.
2) if you want to maintain transactions, use a combination of autovacuum=20
and vacuum delay to do more-or-less continuous low-level vacuuming of the=20
table.  Using Postgres 8.1 will help you to be able to manage this.

=2D-=20
=2D-Josh

Josh Berkus
Aglio Database Solutions
San Francisco