Bruce Momjian wrote: > Tom Lane wrote: > > Dimitri Fontaine <dfonta...@hi-media.com> writes: > > > Josh Berkus <j...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
