GitHub user my-ship-it added a comment to the discussion: [Feature] It's time to discard the resource queue
Really like the direction — both points align with where GPDB has been heading, and the `ResQueueLock` argument for flipping the default to `none` is compelling on its own. The referenced commit (`82851a0`) gives a clean blueprint. 👍 A few clarifying questions before this turns into a PR, mostly to scope it cleanly: **1. "Discard" — full removal, or default-off + deprecate?** The title says *discard*, but GPDB's landed approach was closer to "default `none`, keep the queue implementation around." Very different in effort: full removal means dropping `pg_resqueue`, the `CREATE/ALTER/DROP RESOURCE QUEUE` DDL, queue-aware executor paths, and an upgrade story. I'd lean toward default-off + deprecate for at least one release — which did you have in mind? **2. Upgrade semantics.** For clusters today with `gp_resource_manager = 'queue'` or populated `pg_resqueue` — does the default flip apply only to fresh initdb, or also `pg_upgrade`? Safest: existing explicit config keeps working, default change is fresh-cluster only. **3. Migration guide.** Most resource-queue fields map cleanly to resource groups, but **cost-based admission** (`MAX_COST` / `MIN_COST` / `COST_OVERCOMMIT`) has no 1:1 equivalent — worth calling out what we recommend users do with those. 🙏 GitHub link: https://github.com/apache/cloudberry/discussions/1721#discussioncomment-16888513 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
