Re: WAL Bypass for indexes - Mailing list pgsql-hackers
From | Martin Scholes |
---|---|
Subject | Re: WAL Bypass for indexes |
Date | |
Msg-id | thNYCClvwcMF.JB5pFHmP@mail.iicolo.com Whole thread Raw |
In response to | WAL Bypass for indexes ("Martin Scholes" <marty@iicolo.com>) |
Responses |
Re: WAL Bypass for indexes
("Jonah H. Harris" <jonah.harris@gmail.com>)
Re: WAL Bypass for indexes (Tom Lane <tgl@sss.pgh.pa.us>) Re: WAL Bypass for indexes (Simon Riggs <simon@2ndquadrant.com>) |
List | pgsql-hackers |
<div align="LEFT">Ok Tom, I stand corrected.</div><div align="LEFT"> </div><div align="LEFT">I downloaded the latest snapshotand both scenarios (normal and WAL bypass for indexes) produced between 185 and 230 tps on my machine.</div><divalign="LEFT"> </div><div align="LEFT">The lesson here is that whatever WAL magic has been performed onthe latest release gives over 100% speedup, and the speedup is so good that skipping WAL for indexes does basically nothing.</div><divalign="LEFT"> </div><div align="LEFT">Kudos.</div><div align="LEFT"> </div><div align="LEFT">Cheers,</div><divalign="LEFT">M</div><div align="LEFT">_____ Original message _____</div><div align="LEFT">Subject:Re: [HACKERS] WAL Bypass for indexes </div><div align="LEFT">Author: Tom Lane <tgl@sss.pgh.pa.us></div><divalign="LEFT">Date: 02nd April 2006 5:17:50 PM</div><div align="LEFT"> </div><div align="LEFT">"MartinScholes" <marty@iicolo.com> writes:<br />> I did some informal testing using pgbench on v8.07.First, I ran pgbench =<br />> normally with 75 users doing 100 transactions, full vacuuming between runs. =<br />>My machine consistently gave me 92 tps.<br /></div><div align="LEFT">> As an experiment, I commented out of thebtree index source all of the XLOG =<br />> code I could find. I basically replaced the test for a temp table with"if =<br />> (0)" and then recompiled.<br /></div><div align="LEFT">It'd be more interesting if you'd done this testingon 8.1, or better<br />CVS HEAD, as we took several steps to improve WAL performance in 8.1<br />(notably, abandoningthe 64-bit CRC code). Also, when you don't say</div><div align="LEFT">what configuration you were testing, thetest results don't mean a lot.<br />The cost of WAL logging is *very* heavily influenced by things such as<br />checkpointfrequency, whether you have a separate drive for WAL, etc.<br /></div><div align="LEFT">> It seems to me thatmajor performance gains can be had by allowing some =<br />> indexes to be created with some "UNSAFE-FAIL" flag,<br/></div><div align="LEFT">This might be worth doing, but I'd want to see a more convincing<br />demonstration beforeputting effort into it ...<br /></div><div align="LEFT"> regards, tom lane<br /></div>
pgsql-hackers by date: