Re: WAL Bypass for indexes - Mailing list pgsql-hackers
From | Martin Scholes |
---|---|
Subject | Re: WAL Bypass for indexes |
Date | |
Msg-id | PyhRxcGG8sRX.rrDzBw1p@mail.iicolo.com Whole thread Raw |
In response to | WAL Bypass for indexes ("Martin Scholes" <marty@iicolo.com>) |
List | pgsql-hackers |
<div align="LEFT">Tom Lane wrote:</div><div align="LEFT"> </div><div align="LEFT">> [ scratches head ... ] Actually, I'dhave expected that you could still<br />> measure a difference. I thought it might be reduced to the point where<br/> > we arguably shouldn't spend major effort on eliminating it. But no</div><div align="LEFT">> differenceat all really does not compute.</div><div align="LEFT"> </div><div align="LEFT">I agree completely and was baffledby the observations. I will do some more testing tonight to see if I can pin things down.</div><div align="LEFT"> </div><divalign="LEFT">My machine is a cheapo Wal-Mart Compaq Presario, Sempron 3000+ (2Ghz, socket A, 512KBcache), 768 MB, with the stock 40 GB IDE drive mirrored to a 160 GB SATA drive.</div><div align="LEFT"> </div><div align="LEFT">Irun Mandrake 2006 with the latest patches and ran the Pg snapshot with all of the defaults.</div><div align="LEFT"> </div><divalign="LEFT">I should have seen a difference in speed, but did not. One possible explanation is thatboth tests had the TPS flopping around between 185 and 225. It is possible that the improvement was so small comparedto the variance that it was hard to see. I will run multiple tests and post the actual numbers.</div><div align="LEFT"> </div><divalign="LEFT">Cheers,</div><div align="LEFT">M</div><div align="LEFT"> </div><div align="LEFT">_____Original message _____</div><div align="LEFT">Subject: Re: [HACKERS] WAL Bypass for indexes </div><divalign="LEFT">Author: Tom Lane <tgl@sss.pgh.pa.us></div><div align="LEFT">Date: 02nd April 2006 10:48:19 PM</div><divalign="LEFT"> </div><div align="LEFT">"Martin Scholes" <marty@iicolo.com> writes:<br />> Ok Tom, I standcorrected.<br /></div><div align="LEFT">> I downloaded the latest snapshot and both scenarios (normal and WAL bypass=<br />> for indexes) produced between 185 and 230 tps on my machine.<br /></div><div align="LEFT">> The lessonhere is that whatever WAL magic has been performed on the latest =<br />> release gives over 100% speedup, and thespeedup is so good that skipping =<br />> WAL for indexes does basically nothing.<br /></div><div align="LEFT">[ scratcheshead ... ] Actually, I'd have expected that you could still<br />measure a difference. I thought it might be reducedto the point where<br />we arguably shouldn't spend major effort on eliminating it. But no</div><div align="LEFT">differenceat all really does not compute. Could you recheck your test<br />conditions? You still haven't beenvery clear what they are.<br /></div><div align="LEFT"> regards, tom lane<br /></div><div align="LEFT">---------------------------(endof broadcast)---------------------------<br />TIP 5: don't forget to increaseyour free space map settings<br /></div>
pgsql-hackers by date: