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
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 |