All this talk of WAL writing lately has me wondering something I haven't
spent enough time looking at the source to figure out myself this
week...any good rules of thumb out there for estimating WAL volume? I'm
used to just measuring it via benchmarking but it strikes me a formula
would be nice to have for pre-planning.

For example, if I have a table where a typical row is X bytes wide, and
I'm updating Y of those per second, what's the expected write rate of WAL
volume? Some % of those writes are going to be full pages; what's
typical? How much does the number and complexity of indexes factor into
things--just add the width of the index in bytes to the size of the
record, or is it worse than that?

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Wed, 2007-07-11 at 23:10 -0400, Greg Smith wrote:
> All this talk of WAL writing lately has me wondering something I haven't
> spent enough time looking at the source to figure out myself this
> week...any good rules of thumb out there for estimating WAL volume? I'm
> used to just measuring it via benchmarking but it strikes me a formula
> would be nice to have for pre-planning.
>
> For example, if I have a table where a typical row is X bytes wide, and
> I'm updating Y of those per second, what's the expected write rate of WAL
> volume? Some % of those writes are going to be full pages; what's
> typical? How much does the number and complexity of indexes factor into
> things--just add the width of the index in bytes to the size of the
> record, or is it worse than that?

I published an analysis of WAL traffic from Greg Stark earlier, based
upon xlogdump.

http://archives.postgresql.org/pgsql...3/msg01589.php

Other details of WAL volumes are in the code. Further analysis would be
welcome, to assist discussions of where to optimize next.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly