On Oct 22, 2010, at 1:06 PM, Rob Wultsch wrote: > On Fri, Oct 22, 2010 at 12:05 PM, Kevin Grittner > <Kevin.Grittner@xxxxxxxxxxxx> wrote: >> Rob Wultsch <wultsch@xxxxxxxxx> wrote: >> >>> I would think full_page_writes=off + double write buffer should be >>> far superior, particularly given that the WAL is shipped over the >>> network to slaves. >> >> For a reasonably brief description of InnoDB double write buffers, I >> found this: >> >> http://www.mysqlperformanceblog.com/2006/08/04/innodb-double-write/ >> >> One big question before even considering this would by how to >> determine whether a potentially torn page "is inconsistent". >> Without a page CRC or some such mechanism, I don't see how this >> technique is possible. >> >> Even if it's possible, it's far from clear to me that it would be an >> improvement. The author estimates (apparently somewhat loosely) >> that it's a 5% to 10% performance hit in InnoDB; I'm far from >> certain that full_page_writes cost us that much. Does anyone have >> benchmark numbers handy? >> >> -Kevin >> > > Ignoring (briefly) the cost in terms of performance of the different > system, not needing full_page_writes would make geographically > dispersed replication possible for certain cases where it is not > currently (or at least rather painful).. Am I missing something here? Can't the network replication traffic be partial pages, but the WAL log on the slave (and master) be full pages? In other words, the slave can transform a partial page update into a full page xlog entry. (optional) 1. Log partial pages received from master to disk. (not xlog, something else, useful to persist changes faster) 2. Read page from disk for update. 3. Log full page modification to xlog for local commit. 4. Update page in memory and write out to OS as usual. The lack of the full page from the master would mean that you have to do a read-modify-write rather than just overwrite, but I think that works fine if network bandwidth is your bottleneck. I don't know enough of the guts of Postgres to be certain, but it seems conceptually like this is possible. Also one could use lzo compression and get a likely factor of two space saving with small CPU cost. > > -- > Rob Wultsch > wultsch@xxxxxxxxx > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
