> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Considering those three factors, I think we should consider pushing the > default value up somewhat higher for v10. Reverting to the 64MB size that > we had prior to 47937403676d913c0e740eec6b85113865c6c8ab > sounds pretty reasonable.
+1 The other downside is that the response time of transactions may degrade when they have to wait for a new WAL segment to be created. Tha might pop up as occasional slow or higher maximum response time, which is a mystery to users. Maybe it's time to use posix_fallocate() to create WAL segments. > Possibly it would make sense for this to be configurable at initdb time > instead of requiring a recompile; we probably don't save any significant > number of cycles by compiling this into the server. +1 > 3. archive_timeout is no longer a frequently used option. Obviously, if > you are frequently archiving partial segments, you don't want the segment > size to be too large, because if it is, each forced segment switch > potentially wastes a large amount of space (and bandwidth). > But given streaming replication and pg_receivexlog, the use case for > archiving partial segments is, at least according to my understanding, a > lot narrower than it used to be. So, I think we don't have to worry as > much about keeping forced segment switches cheap as we did during the 8.x > series. I'm not sure about this. I know (many or not) users use continuous archiving with archive_command and archive_timeout for backups, and don't want to use streaming replication, because the system is not worth the cost and trouble of HA. I heard from a few users that they were surprised when they knew that PostgreSQL generates WAL even when no update transaction is happening. Is this still true? Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
