From: Josh Berkus <josh@agliodbs.com>
To: pgsql-performance@postgresql.org
Cc: Kenji Morishige <kenjim@juniper.net>
Subject: Re: optimizing db for small table with tons of updates
Date: Mon, 3 Apr 2006 11:29:42 -0700
Message-ID: <200604031129.42194.josh@agliodbs.com> (raw)
In-Reply-To: <20060403182403.GA12257@juniper.net>
References: <20060403182403.GA12257@juniper.net>
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.
You're correct.
> Are there any table options that enables
> 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
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
and vacuum delay to do more-or-less continuous low-level vacuuming of the
table. Using Postgres 8.1 will help you to be able to manage this.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: josh@agliodbs.com, kenjim@juniper.net
Subject: Re: optimizing db for small table with tons of updates
In-Reply-To: <200604031129.42194.josh@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox