Re: WAL Bypass for indexes

Поиск
Список
Период
Сортировка
От Martin Scholes
Тема Re: WAL Bypass for indexes
Дата
Msg-id PyhRxcGG8sRX.rrDzBw1p@mail.iicolo.com
обсуждение исходный текст
Ответ на WAL Bypass for indexes  ("Martin Scholes" <marty@iicolo.com>)
Список 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 по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: Postgres dies when using an intarray operator
Следующее
От: Horváth Sándor
Дата:
Сообщение: deferrable check, trigger