>I am sorry but I can't understand the above results due to wrapping.
>Are you saying compression was twice as slow?
CPU usage at user level (in seconds) for compression set 'on' is 562 secs
while that for compression set 'off' is 354 secs. As per the readings, it
takes little less than double CPU time to compress.
However , the total time taken to run 250000 transactions for each of the
scenario is as follows,
compression = 'on' : 1838 secs
= 'off' : 1701 secs
Different is around 140 secs.
Thank you,
Rahila Syed
On Wed, Dec 10, 2014 at 7:55 PM, Bruce Momjian <br...@momjian.us> wrote:
> On Wed, Dec 10, 2014 at 07:40:46PM +0530, Rahila Syed wrote:
> > The tests ran for around 30 mins.Manual checkpoint was run before each
> test.
> >
> > Compression WAL generated %compression Latency-avg CPU usage
> > (seconds) TPS
> Latency
> > stddev
> >
> >
> > on 1531.4 MB ~35 % 7.351 ms
>
> > user diff: 562.67s system diff: 41.40s 135.96
>
> > 13.759 ms
> >
> >
> > off 2373.1 MB 6.781
> ms
> > user diff: 354.20s system diff: 39.67s 147.40
>
> > 14.152 ms
> >
> > The compression obtained is quite high close to 35 %.
> > CPU usage at user level when compression is on is quite noticeably high
> as
> > compared to that when compression is off. But gain in terms of reduction
> of WAL
> > is also high.
>
> I am sorry but I can't understand the above results due to wrapping.
> Are you saying compression was twice as slow?
>
> --
> Bruce Momjian <br...@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + Everyone has their own god. +
>
