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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
