Re: PostgreSQL as a local in-memory cache
От | Bruce Momjian |
---|---|
Тема | Re: PostgreSQL as a local in-memory cache |
Дата | |
Msg-id | 201006282157.o5SLvQ922390@momjian.us обсуждение исходный текст |
Ответ на | Re: PostgreSQL as a local in-memory cache (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: PostgreSQL as a local in-memory cache
|
Список | pgsql-performance |
Bruce Momjian wrote: > Tom Lane wrote: > > Dimitri Fontaine <dfontaine@hi-media.com> writes: > > > Josh Berkus <josh@agliodbs.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. > > Based on this thread, I have developed the following documentation patch > that outlines the performance enhancements possible if durability is not > required. The patch also documents that synchronous_commit = false has > potential committed transaction loss from a database crash (as well as > an OS crash). Applied. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
В списке pgsql-performance по дате отправления: