From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL as a local in-memory cache |
Date: | 2010-06-17 19:38:30 |
Message-ID: | 24597.1276803510@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> a) Eliminate WAL logging entirely
>> b) Eliminate checkpointing
>> c) Turn off the background writer
>> d) Have PostgreSQL refuse to restart after a crash and instead call an
>> exteral script (for reprovisioning)
> Well I guess I'd prefer a per-transaction setting, allowing to bypass
> WAL logging and checkpointing.
Not going to happen; this is all or nothing.
> Forcing the backend to care itself for
> writing the data I'm not sure is a good thing, but if you say so.
Yeah, I think proposal (c) is likely to be a net loss.
(a) and (d) are probably simple, if by "reprovisioning" you mean
"rm -rf $PGDATA; initdb". Point (b) will be a bit trickier because
there are various housekeeping activities tied into checkpoints.
I think you can't actually remove checkpoints altogether, just
skip the flush-dirty-pages part.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-06-17 19:59:39 | Re: PostgreSQL as a local in-memory cache |
Previous Message | Dimitri Fontaine | 2010-06-17 19:01:19 | Re: PostgreSQL as a local in-memory cache |