Re: WAL Bypass for indexes

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martin Scholes <marty(at)iicolo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL Bypass for indexes
Date: 2006-04-03 15:27:38
Message-ID: 1144078058.3766.5.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ühel kenal päeval, E, 2006-04-03 kell 01:48, kirjutas Tom Lane:
> "Martin Scholes" <marty(at)iicolo(dot)com> writes:
> > Ok Tom, I stand corrected.
>
> > I downloaded the latest snapshot and both scenarios (normal and WAL bypass =
> > for indexes) produced between 185 and 230 tps on my machine.
>
> > The lesson here is that whatever WAL magic has been performed on the latest =
> > release gives over 100% speedup, and the speedup is so good that skipping =
> > WAL for indexes does basically nothing.
>
> [ scratches head ... ] Actually, I'd have expected that you could still
> measure a difference. I thought it might be reduced to the point where
> we arguably shouldn't spend major effort on eliminating it. But no
> difference at all really does not compute. Could you recheck your test
> conditions? You still haven't been very clear what they are.

Actually I can imagine a condition where there is no difference:

When the additional WAL records for indexes are written in one swoop,
and you write 1 batch of WAL records per disk rotation, there is very
small difference between writing 1k WAL record and 32k wal record.

In other words, if you are writing the same number of smaller records
per commit, you get *exactly the same performance as OLTP is constrained
mainly by iops, not throughput.

------------------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2006-04-03 15:33:57 Re: WAL Bypass for indexes
Previous Message Simon Riggs 2006-04-03 14:28:50 Re: WAL Bypass for indexes