zillablog - Comments

Anonymous: Checkpoints, Buffers, and Graphs

nospam@example.com () — Tue, 20 Dec 2011 10:49:50 -0500

thanks for the slides and the post.

Greg Smith: Checkpoints, Buffers, and Graphs

nospam@example.com (Greg Smith) — Sun, 27 Nov 2011 15:42:51 -0500

And the slides are up at http://www.2ndquadrant.com/en/talks/

Alvaro: Index pruning techniques

nospam@example.com (Alvaro) — Thu, 24 Nov 2011 11:42:54 -0500

You probably want array_agg instead of array_accum. That said, if you don't understand how to fix the query, it's unlikely that you'd be able to interpret the results either.

Jim Mlodgenski: Checkpoints, Buffers, and Graphs

nospam@example.com (Jim Mlodgenski) — Wed, 16 Nov 2011 17:11:42 -0500

For people in the New York area, Greg will be giving the same talk at the NYCPUG meeting tomorrow. Go to http://www.nycpug.org/ to RSVP. There are still a few spots available.

Robert Treat: Understanding Postgres Durability Options

nospam@example.com (Robert Treat) — Fri, 11 Nov 2011 18:23:56 -0500

Hmm, ISTR a problem with running non-full-page-writes with WAL based replication, though you could probably do this using something like Slony. The danger here is that I think you might be risking corruption even in non-crash situations. That might just be paranioa, but I don't think the non-full-page-writes code paths are used very often (and it's hard to think of a scenario where I would want to test it).

Robert Treat: Understanding Postgres Durability Options

nospam@example.com (Robert Treat) — Fri, 11 Nov 2011 18:19:32 -0500

I thought about mentioning synch rep, but I don't really see it as a pure durability play; imagine two synch rep'd servers where both have fsync off. (This isn't as horrible as it sounds). It does help with data persistence and availability, so it's probably worth mentioning.

Tomas: Understanding Postgres Durability Options

nospam@example.com (Tomas) — Thu, 10 Nov 2011 09:08:12 -0500

It's worth stressing out that the delayed commits (commit_delay/commit_siblings) don't trade durability for performance - it's rather latency vs. throughput. I.e. you can get higher throughput for higher latencies.

And I wouldn't say it's less granular than the synchronous_commit option - you can enable or disable it for each transaction IIRC, plus you can tune the number of required siblings (when there's less transactions in progress, it does not wait). Sure - when the transactions are idle for some reason or take very long to complete, it won't help.

eremneday: Understanding Postgres Durability Options

nospam@example.com (eremneday) — Wed, 09 Nov 2011 07:08:45 -0500

Skimming through your text I have stumbled upon solutions for number of questions that have been bugging me for long time now. Its troublesome to find up to date texts on the web as plenty of the publications are written by a person with little interest in the subject. Your article is well written and definitively worth recommending. I'll come back for more in few days.
View: linkman.pl.

Robert Treat: Understanding Postgres Durability Options

nospam@example.com (Robert Treat) — Tue, 08 Nov 2011 10:57:03 -0500

fixed, thanks

Emanuel: Understanding Postgres Durability Options

nospam@example.com (Emanuel) — Tue, 08 Nov 2011 10:56:35 -0500

You can sacrifice durability among performance turning off full_page_writes if you have async replicated servers.