On Thu, Feb 20, 2014 at 9:43 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > The design choice of making the limit only apply to bulk ops is > because that is where the main problem lies. Rate limiting will cause > a loss of performance in the main line for non-bulk operations, so > adding tests there will not be valuable.
That's pure sophistry. Of course rate limiting will cause "a loss of performance in the main line for non-bulk operations". Rate limiting will also cause a loss of performance for bulk operations. The whole point of rate limiting is to cause a loss of performance. That's not a bug; that's what the feature is explicitly designed to do. So-called "non-bulk operations", which seems to be defined as more or less "anything where actually making this feature work seemed hard", can include huge inserts, updates, or deletes that greatly depress performance for other parts of the system, either individually or in aggregate. And it's just as legitimate to want to tamp down that activity as it is to want to slow down CLUSTER. Remember, this is a GUC, so it need not be set identically for every user session. It is not hard at all to imagine a situation where the user wishes to limit the rate at which some sessions can write WAL so as to avoid interfering with other, higher-priority tasks happening in other sessions. That is hardly a niche use case; I think I've seen it reported, if anything, even more frequently than problems with what you're calling bulk operations. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
