From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: Write Amplification Reduction Method (WARM) |
Date: | 2017-02-23 15:51:46 |
Message-ID: | 20170223155146.GJ20486@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 31, 2017 at 04:52:39PM +0530, Pavan Deolasee wrote:
> The other critical bug I found, which unfortunately exists in the master too,
> is the index corruption during CIC. The patch includes the same fix that I've
> proposed on the other thread. With these changes, WARM stress is running fine
> for last 24 hours on a decently powerful box. Multiple CREATE/DROP INDEX cycles
> and updates via different indexed columns, with a mix of FOR SHARE/UPDATE and
> rollbacks did not produce any consistency issues. A side note: while
> performance measurement wasn't a goal of stress tests, WARM has done about 67%
> more transaction than master in 24 hour period (95M in master vs 156M in WARM
> to be precise on a 30GB table including indexes). I believe the numbers would
> be far better had the test not dropping and recreating the indexes, thus
> effectively cleaning up all index bloats. Also the table is small enough to fit
> in the shared buffers. I'll rerun these tests with much larger scale factor and
> without dropping indexes.
Thanks for setting up the test harness. I know it is hard but
in this case it has found an existing bug and given good performance
numbers. :-)
I have what might be a supid question. As I remember, WARM only allows
a single index-column change in the chain. Why are you seeing such a
large performance improvement? I would have thought it would be that
high if we allowed an unlimited number of index changes in the chain.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-02-23 16:08:45 | Re: Documentation improvements for partitioning |
Previous Message | Dilip Kumar | 2017-02-23 15:50:04 | Re: Enabling parallelism for queries coming from SQL or other PL functions |