Robert Haas escribió:
> 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.
I think he's saying that it will degrade performance even in the case
where the feature is disabled, which would be undesirable. I don't
necessarily agree with that assertion, but at least it's something to
consider rather than to laugh at.
> 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.
I don't disagree with this either, but I don't think it necessarily has
to be the same feature. Most likely we don't want to have users setting
the GUC each time they want to run vacuum; rather they will want to be
able to set one line in postgresql.conf and have it affect all vacuuming
activity. However, if that same config tweak affects all their UPDATE
statements regardless of them being single-row updates or bulk updates,
I'm pretty sure it's not going to be welcome.
I think "bulk" (maintenance) operations should legitimately configured
separately from regular UPDATE etc operations. For the latter I think
it's pretty reasonable to assume that users are going to want to tweak
the GUC for each individual callsite in the application, rather than
wholesale in postgresql.conf.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
