Re: question about frequency of updates/reads

From: David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Andrew Smith <laconical(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: question about frequency of updates/reads
Date: 2009-06-24 05:05:28
Message-ID: e7f9235d0906232205t637aca0cwe11fa94c45082f52@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jun 24, 2009 at 12:48 AM, Scott Marlowe<scott(dot)marlowe(at)gmail(dot)com> wrote:

> Maybe.  Rows that are updated often are NOT generally pgsql's strong
> suit, but IF you're running 8.3 or above, and IF you have a low enough
> fill factor that there's empty space for the updates and IF the fields
> you are updating are not indexed and IF you have aggressive enough
> vacuuming and IF you restrict your updates to JUST real updates (i.e.
> update ... set a=1 where a<>1) and IF your IO subsystem has enough raw
> horsepower, you can make this work.  But only benchmarking will tell
> you if you can do it with your current hardware and setup.

One option, though not nearly as nice as a simple additional table, is
to initdb on a ramdisk and run a separate server instance on it. It
doesn't sound like a) you've got a lot of data in there, or b) you
really care about the data sticking around after a crash (since it's
in the proprietary system already). You'd get the benefit of easy sql
to do the storage and retrieval, though you'd need a separate
connection to the separate server instance on the web page which would
be annoying, and you'd probably want to script the ramdisk and db
setup since you'll have to recreate after a crash. (Alternately,
create on disk somewhere; then put a copy on the ramdisk and start a
postgres instance pointed at it. Then after a restart you just need to
copy over from disk and start up the postgres instance)

--
- David T. Wilson
david(dot)t(dot)wilson(at)gmail(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sim Zacks 2009-06-24 05:24:06 Re: after vacuum analyze, explain still wrong
Previous Message Scott Marlowe 2009-06-24 04:48:52 Re: question about frequency of updates/reads