Tom Lane wrote:
Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
In a steady-state situation new WAL files are not created very often
because we recycle old ones, so it probably doesn't make much difference.
Yeah. We really don't worry too much about the performance of the
new-WAL-file-creation code path because of this.
The only situation where the WAL zeroing path turns ugly is if you
launch a bunch of activity against a fresh server that doesn't have any
segments to recycle yet. The last time we talked about improving that,
the best idea I thought came out was to be better about preallocating
segments than the code already is, rather than trying to speed up how
the kernel deals with the situation. See the links for "Be more
aggressive about creating WAL files" at http://wiki.postgresql.org/wiki/Todo
I'm also not very optimistic about adding more posix_fadvise calls
really helping just because the implementations of those are so
unpredictable across operating systems. I'm sure that Mark could figure
out the right magic to speed up this specific case on Linux, but have my
doubts that work would translate very well to many other operating
systems. Whereas a more generic preallocation improvement would help
everywhere.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
