Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Дата
Msg-id 20170223155146.GJ20486@momjian.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Ответы Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Robert Haas <robertmhaas@gmail.com>)
Список 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@momjian.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 +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] Documentation improvements for partitioning