| From: | "Pierre C" <lists(at)peufeu(dot)com> |
|---|---|
| To: | "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, "Josh Berkus" <josh(at)agliodbs(dot)com> |
| Cc: | "postgres performance list" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL as a local in-memory cache |
| Date: | 2010-06-17 20:12:25 |
| Message-ID: | op.vegnqzoxeorkce@apollo13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> Well I guess I'd prefer a per-transaction setting, allowing to bypass
> WAL logging and checkpointing. Forcing the backend to care itself for
> writing the data I'm not sure is a good thing, but if you say so.
Well if the transaction touches a system catalog it better be WAL-logged...
A per-table (or per-index) setting makes more sense IMHO. For instance "on
recovery, truncate this table" (this was mentioned before).
Another option would be "make the table data safe, but on recovery,
destroy and rebuild this index" : because on a not so large, often updated
table, with often updated indexes, it may not take long to rebuild the
indexes, but all those wal-logged index updates do add some overhead.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-06-17 21:41:54 | Re: requested shared memory size overflows size_t |
| Previous Message | Greg Smith | 2010-06-17 19:59:39 | Re: PostgreSQL as a local in-memory cache |