On 16 January 2014 17:20, Simon Riggs <si...@2ndquadrant.com> wrote: > Thank you everyone for responding so positively to this proposal. It > is something many users have complained about. > > In time, I think we might want both WAL Rate Limiting and I/O Rate > Limiting. IMHO I/O rate limiting is harder and so this proposal is > restricted solely to WAL rate limiting. > > I'm comfortable with a session level parameter. I was mulling over a > wal_rate_limit_scope parameter but I think that is too much. > I will follow Craig's proposal to define this in terms of MB/s, adding > that I would calc from beginning of statement to now, so it is > averaged rate. Setting of zero means unlimited. The rate would be > per-session (in this release) rather than a globally calculated > setting.
Parameter renamed to wal_rate_limit. Not yet modified to produce this in MB/s > I would like to call it CHECK_FOR_WAL_RATE_LIMIT() Used CHECK_WAL_BUDGET() as proposed > That seems like a cheap enough call to allow it to be added in more > places, so my expanded list of commands touched are > CLUSTER/VACUUM FULL > ALTER TABLE (only in phase 3 table rewrite) > ALTER TABLE SET TABLESPACE > CREATE INDEX > which are already there, plus new ones suggested/implied > COPY > CREATE TABLE AS SELECT > INSERT/UPDATE/DELETE Added, no problems or technical difficulties encountered. > Please let me know if I missed something (rather than debating what is > or is not a "maintenance" command). > > Any other thoughts before I cut v2 ? v2 attached -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers