Re: PostgreSQL as a local in-memory cache
От | Dimitri Fontaine |
---|---|
Тема | Re: PostgreSQL as a local in-memory cache |
Дата | |
Msg-id | m2typ18ow0.fsf@hi-media.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL as a local in-memory cache (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: PostgreSQL as a local in-memory cache
Re: PostgreSQL as a local in-memory cache Re: PostgreSQL as a local in-memory cache |
Список | pgsql-performance |
Hi, 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. Forcing the backend to care itself for writing the data I'm not sure is a good thing, but if you say so. Then you could have the GUC set for a whole cluster, only a database etc. We already have synchronous_commit to trade durability against performances, we could maybe support protect_data = off too. The d) point I'm not sure still applies if you have per transaction setting, which I think makes the most sense. The data you choose not to protect is missing at restart, just add some way to register a hook there. We already have one (shared_preload_libraries) but it requires coding in C. Calling a user function at the end of recovery and before accepting connection would be good I think. A user function (per database) is better than a script because if you want to run it before accepting connections and still cause changes in the database… Regards, -- dim
В списке pgsql-performance по дате отправления: