On Thu, Feb 20, 2014 at 10:10 AM, Greg Stark <stark@mit.edu> wrote:
> On Thu, Feb 20, 2014 at 2:43 PM, 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.
>
> This isn't a bad point. If you do a massive UPDATE or INSERT you
> probably do want the ability to limit the damage to your replication
> lag but if you're an OLTP worker and you just happen to handle a
> disproportionate amount of the incoming requests you wouldn't. But
> then presumably you would just set that GUC that way where your OLTP
> workers would run without any limits and your batch jobs would set a
> limit.
>
> As I said it wouldn't be terrible if the patch went in and could only
> handle cluster/vacuum/create index. They're by far the most common
> causes of problems and most people who do massive UPDATES or INSERTS
> quickly discover they want to do it in batches of a few thousand rows
> anyways so they can limit the speed themselves.
>
> There's a decent argument to made for incremental changes too. If we
> add a feature like this for these operations then we'll find out how
> well it works in practice and whether users need finer control or what
> other sources become the next problem before we've invested a whole
> lot in a general solution.
What will more likely happen is that we won't be able to change the
definition in future releases because it breaks backward
compatibility. If we implement this now for only a subset of
commands, and then later someone proposes a patch to expand it to more
commands, then there's going to be someone who shows up and complains
about that definitional change. And for good reason.
I'm heartily in favor of incremental development of features, but each
incremental addition needs to stand on its own two feet, not be
something that we can already foresee needing to break or throw out
later. There are way, way too many PostgreSQL users now for us to be
able to get away with that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
