WAL Bypass for indexes

<div align="LEFT">I have followed the discussion from 3 months ago on WAL bypass and wanted to offer some more
information.</div><divalign="LEFT"> </div><div align="LEFT">I have long believed that the bottleneck in
transaction-orientedsystems is the writing of the indexes, complete with splits and merges. A single update to one
fieldof a heavily-indexed table could cause dozens of index writes to cascade.</div><div align="LEFT"> </div><div
align="LEFT">Thepoint is that speeding up index writing should offer the most "bang for the buck" relative to
performance.As a bonus, a corrupted index can ALWAYS be recovered, while a corrupted table cannot.</div><div
align="LEFT"> </div><divalign="LEFT">I did some informal testing using pgbench on v8.07. First, I ran pgbench normally
with75 users doing 100 transactions, full vacuuming between runs. My machine consistently gave me 92 tps.</div><div
align="LEFT"> </div><divalign="LEFT">As an experiment, I commented out of the btree index source all of the XLOG code I
couldfind. I basically replaced the test for a temp table with "if (0)" and then recompiled.</div><div
align="LEFT"> </div><divalign="LEFT">Running again pgbench with 75 users and 100 transactions, I received a consistent
rateof 132 tps, a 40% increase in throughput.</div><div align="LEFT"> </div><div align="LEFT">It seems to me that major
performancegains can be had by allowing some indexes to be created with some "UNSAFE-FAIL" flag, which would eliminate
WALlogging and fsync() for the index files.</div><div align="LEFT"> </div><div align="LEFT">Upon recovery, the index
getsrebuilt. The only downside is potentially long rebuild times during recovery.</div><div align="LEFT"> </div><div
align="LEFT">Thoughts?</div><divalign="LEFT"> </div><div align="LEFT">Sincerely,</div><div align="LEFT">Marty</div>