5 ms·

Are you legit suggesting tying the cost of GC to transaction commit in a database platform that is very commonly used for OLTP workloads?

by rosser 9y ago

hinkley 9y ago
Those are exactly the systems that are falling over already, aren’t they? They’re already tied together whether that’s inconvenient or not. Right now (or at least, recently) the performance simply falls off a cliff instead of degrading. A lot of the tools we have for dealing with down services also can deal with degraded ones. If for instance throttling votes per second keeps the system usable for everyone else then that has been done before and can be done again. But you have to do it before the database has a seizure, not after. [edit: I’m talking about back pressure. This is not a new or crazy concept. Your incredulity and $5 will buy me a cup of coffee]
- rosser 9y ago
  I wouldn't characterize things as "falling over", except perhaps in cases of operator incompetence. There's certainly room for improvement — The Fine Article wouldn't exist otherwise — and backpressure might be worth exploring as a means of improving things. If that backpressure causes the system to slow down in a way that adversely affects customer or end-user interactions, however, it will often just be turned off, mooting it — or making things worse.
  - hinkley 9y ago
    Like a lot of people, I was barely aware of VACUUMing before several high profile OLTP systems had unplanned outages because Postgres' requests per second dropped off dramatically and suddenly due to this arcane form of resource exhaustion. That's a performance cliff. I didn't mean it is hyperbole but as jargon. System hits a bottleneck, rate-of-change alters drastically/unmanageably.
    - rosser 9y ago
      That sounds like operator error to me. If you (the general "you") use a database in production without knowing what sorts of maintenance it requires, that's neither the database's nor its authors' fault. I guess you could argue the tool is somehow "flawed" for needing maintenance. I'd counter with the invitation to show me tools that don't.

Are you legit suggesting tying the cost of GC to transaction commit in a database platform that is very commonly used for OLTP workloads?

by rosser 9y ago

Are you legit suggesting tying the cost of GC to transaction commit in a database platform that is very commonly used for OLTP workloads?

hinkley 9y ago

Those are exactly the systems that are falling over already, aren’t they? They’re already tied together whether that’s inconvenient or not. Right now (or at least, recently) the performance simply falls off a cliff instead of degrading. A lot of the tools we have for dealing with down services also can deal with degraded ones. If for instance throttling votes per second keeps the system usable for everyone else then that has been done before and can be done again. But you have to do it before the database has a seizure, not after. [edit: I’m talking about back pressure. This is not a new or crazy concept. Your incredulity and $5 will buy me a cup of coffee]

rosser 9y ago
I wouldn't characterize things as "falling over", except perhaps in cases of operator incompetence. There's certainly room for improvement — The Fine Article wouldn't exist otherwise — and backpressure might be worth exploring as a means of improving things. If that backpressure causes the system to slow down in a way that adversely affects customer or end-user interactions, however, it will often just be turned off, mooting it — or making things worse.
- hinkley 9y ago
  Like a lot of people, I was barely aware of VACUUMing before several high profile OLTP systems had unplanned outages because Postgres' requests per second dropped off dramatically and suddenly due to this arcane form of resource exhaustion. That's a performance cliff. I didn't mean it is hyperbole but as jargon. System hits a bottleneck, rate-of-change alters drastically/unmanageably.
  - rosser 9y ago
    That sounds like operator error to me. If you (the general "you") use a database in production without knowing what sorts of maintenance it requires, that's neither the database's nor its authors' fault. I guess you could argue the tool is somehow "flawed" for needing maintenance. I'd counter with the invitation to show me tools that don't.