On Mon, 2007-02-26 at 09:44 -0500, Bruce Momjian wrote: > Joshua D. Drake wrote: > > Christopher Browne wrote: > > > A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Hideyuki > > > Kawashima) wrote: > > >> I appreciate your great suggestion! > > >> It is great honor for me if Sigres will be merged to PostgreSQL. > > >> Since the changes of Sigres from PostgreSQL-8.2.1 are not many, > > >> and moreover, all of changes are surrounded with #ifdef SIGRES --- > > >> #endif, > > >> incorporating Sigres into PostgreSQL would be easy. > > > > > > You should consider submitting a patch for this against CVS HEAD. > > > > > > And actually, I'd think it a better idea to define a GUC variable and > > > use that to control whether Sigres is active or not. > > > > > > At the more sophisticated end of the spectrum, you might set things up > > > so that it could be activated/deactivated at runtime by a superuser. > > > > > > At the less sophisticated end, it might need to be configured in > > > postgresql.conf... > > > > Whatever happen with this? > > I would like to see more analysis about why Sigres is faster than an > in-memory file system. I think the idea was that locking was reduced > but I am unclear on why locking is different in the two cases.
Reading through the design, I see the following - bgwriter performs XLogWrite, not each backend - WAL fsync is only performed when WAL file fills - no checkpoints are performed until shutdown This is approximately the same performance as fsync=off, with a big boost because we never do checkpoints either (i.e. 10% as stated by the OP). There is a slight gain because of reduced lock contention, but I wouldn't expect that to be major. This comes back to the idea of deferred fsync we've spoken about a few times, to provide "MySQL mode" performance and reduced robustness guarantees. The idea of having a special backend perform the XLogWrites rather than the individual backends is already a TODO item, even if this implementation is somewhat more extreme in its approach to fsync delay. The actual potential data loss is similar to an archive recovery though, so I do like that touch - i.e. we might lose everything in the current WAL file. IMHO, it shouldn't be the bgwriter that fsyncs WAL because it cannot clean shared_buffers and fsync the WAL concurrently with any effectiveness. Perhaps such infrequent fsyncs mean thats not a problem. Not checkpointing at all is not a good plan, since this will lead to an enormous build up of WAL files and a very long recovery time if the system does fail. Overall, these choices effect the whole system whereas what I think we need is something that can be applied to just certain transactions or tables. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
