On Fri, Oct 4, 2013 at 10:49 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Sep 30, 2013 at 1:55 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Mon, Sep 30, 2013 at 10:04 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> On Mon, Sep 30, 2013 at 1:27 PM, KONDO Mitsumasa
>>> <kondo.mitsumasa@lab.ntt.co.jp> wrote:
>>>> Hi Fujii-san,
>>>>
>>>>
>>>> (2013/09/30 12:49), Fujii Masao wrote:
>>>>> On second thought, the patch could compress WAL very much because I used
>>>>> pgbench.
>>>>>
>>>>> I will do the same measurement by using another benchmark.
>>>>
>>>> If you hope, I can test this patch in DBT-2 benchmark in end of this week.
>>>> I will use under following test server.
>>>>
>>>> * Test server
>>>> Server: HP Proliant DL360 G7
>>>> CPU: Xeon E5640 2.66GHz (1P/4C)
>>>> Memory: 18GB(PC3-10600R-9)
>>>> Disk: 146GB(15k)*4 RAID1+0
>>>> RAID controller: P410i/256MB
>>>
>>> Yep, please! It's really helpful!
>>
>> I think it will be useful if you can get the data for 1 and 2 threads
>> (may be with pgbench itself) as well, because the WAL reduction is
>> almost sure, but the only thing is that it should not dip tps in some
>> of the scenarios.
>
> Here is the measurement result of pgbench with 1 thread.
>
> scaling factor: 100
> query mode: prepared
> number of clients: 1
> number of threads: 1
> duration: 900 s
>
> WAL Volume
> - 1344 MB (full_page_writes = on)
> - 349 MB (compress)
> - 78 MB (off)
>
> TPS
> 117.369221 (on)
> 143.908024 (compress)
> 163.722063 (off)
This data is good.
I will check if with the help of my old colleagues, I can get the
performance data on m/c where we have tried similar idea.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com