On Thu, Feb 20, 2014 at 9:43 AM, Simon Riggs <simon@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