| From: | Jesper Krogh <jesper(at)krogh(dot)cc> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Amit kapila <amit(dot)kapila(at)huawei(dot)com>, "hlinnakangas(at)vmware(dot)com" <hlinnakangas(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation |
| Date: | 2012-10-25 16:09:51 |
| Message-ID: | 7FCED621-DFC1-437D-BCD3-F2FE6D1F0EEC@krogh.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Naturally, there are other compression and delta encoding schemes. Does
> anyone feel the need to explore further alternatives?
>
> We might eventually find the need for multiple, user-selectable, WAL
> compression strategies. I don't recommend taking that step yet.
>
my currently implemented compression strategy is to run the wal block through gzip in the archive command. compresses pretty nicely and achieved 50%+ in my workload (generally closer to 70)
on a multi core system it will take more cpu time but on a different core and not have any effect on tps.
General compression should probably only be applied if it have positive gain on tps you could.
Jesper
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Wieck | 2012-10-25 16:16:22 | Re: autovacuum truncate exclusive lock round two |
| Previous Message | Pavel Stehule | 2012-10-25 15:58:58 | Re: proposal - assign result of query to psql variable |