Re: Logging WAL when updating hintbit

From: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
To: Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logging WAL when updating hintbit
Date: 2013-11-20 16:41:57
Message-ID: CAD21AoCqaQz=OBG=x712iNzkn2zH+t_1foSYsgKWNLJBdGDPgw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 20, 2013 at 9:19 PM, Dilip kumar <dilip(dot)kumar(at)huawei(dot)com> wrote:
> On 19 November 2013 22:19, Sawada Masahiko Wrote
>>> >
>>
>> Thanks!
>> I took it wrong.
>> I think that there are quite a few difference amount of WAL.
>>
>> > Did you test about amount of WAL size in your patch?
>>
>> Not yet. I will do that.
>
> 1. Patch applies cleanly to master HEAD.
> 2. No Compilation Warning.
> 3. It works as per the patch expectation.
>
> Some Suggestion:
> 1. Add new WAL level ("all") in comment in postgresql.conf
> wal_level = hot_standby # minimal, archive, or hot_standby

Thank you for reviewing the patch.
Yes, I will do that. And I'm going to implement documentation patch.

>
> Performance Test Result:
> Run with pgbench for 300 seconds
>
> WAL level : hot_standby
> WAL Size : 111BF8A8
> TPS : 125
>
> WAL level : all
> WAL Size : 11DB5AF8
> TPS : 122
>
> * TPS is almost constant but WAL size is increased around 11M.
>
> This is the first level of observation, I will continue to test few more scenarios including performance test on standby.

Thank you for performance testing.
According of test result, TPS of 'all' lower than 'hot_standby',but
WAL size is increased.
I think that it should be separate parameter.
And TPS on master side is is almost constant. so this patch might have
several benefit for performance
improvement on standby side if the result of performance test on
standby side is improved.

Regards,

-------
Sawada Masahiko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-11-20 16:46:22 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Previous Message Nigel Heron 2013-11-20 16:39:52 Re: review: autovacuum_work_mem