You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2019/09/23 18:43:05 UTC
[GitHub] [incubator-druid] gianm commented on issue #6993: [Proposal]
Dynamic prioritization and laning
gianm commented on issue #6993: [Proposal] Dynamic prioritization and laning
URL: https://github.com/apache/incubator-druid/issues/6993#issuecomment-534230983
> True. How I got into referring to this feature as "resource pools" is that I was borrowing the name from Vertica. (https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/AdministratorsGuide/ResourceManager/ManagingWorkloads.htm?tocpath=Administrator%27s%20Guide%7CManaging%20the%20Database%7CManaging%20Workloads%7C_____0)
The Vertica resource pools are a bit more pool-y, they have things like `MAXCONCURRENCY`, `MAXQUERYMEMORYSIZE`, and `PRIORITY` that look like they correspond pretty closely to Druid concepts (see [documentation for CREATE RESOURCE POOL](https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/SQLReferenceManual/Statements/CREATERESOURCEPOOL.htm)).
The `RUNTIMECAP` + `CASCADE TO` mechanism doesn't correspond to any current Druid concept, but maybe it should. It is trying to solve the same problem that @ccaominh brought up.
> Such an approach would be nice in that it is such a generic concept that sophisticated features could be realised later on on that foundation. If on the other hand an "engineered" approach is taken as a foundation, like a fixed, predefined number of lanes with fixed, predefined behaviours, then this limits how many later innovations could be put on top of it.
Would it really be that tough to make the system more flexible in the future? I'd imagine giving the fast and slow lanes special names and then allowing people to define more. We might have to deprecate a couple of config properties, but that doesn't seem too bad.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org