Skip to content

About Changes to Resource Groups in WarehousePG 7


WarehousePG 7 introduces substantial changes to resource group-based resource management. This topic compares the differences between resource groups with WarehousePG 6 and WarehousePG 7. Visit Using Resource Groups for more information about how resource groups work in WarehousePG 7.

The following table compares the main concepts of resource management and how each version of WarehousePG implements them:

MetricResource Groups in WarehousePG 6Resource Groups in WarehousePG 7
ConcurrencyManaged at the transaction levelManaged at the transaction level
CPUSpecify percentage of CPU resources or the number of CPU cores; uses Linux Control GroupsSpecify percentage of CPU resources or the number of CPU cores, as well as set upper limits per resource group; uses Linux Control Groups
MemoryManaged at the transaction level, with enhanced allocation and tracking; users cannot over-subscribeManaged at the transaction level, with enhanced allocation and tracking; users can over-subscribe; simpler and more convenient configuration
Disk I/ONoneLimit the maximum read/write disk I/O throughput, and maximum read/write I/O operations per second
UsersLimits are applied to SUPERUSER and non-admin users alike
There are two default resource groups: admin_group and default_group
Limits are applied to SUPERUSER, non-admin users, and system processes of non-user classes
There are three default resource groups: admin_group, default_group, and system_group
QueueingQueue when no slot is available or not enough available memoryQueue when no slot is available
Query FailureQuery may fail after reaching transaction fixed memory limit when no shared resource group memory exists and the transaction requests more memoryQuery may fail if the allocated memory for the query surpasses the available system memory and spill limits
Limit BypassLimits are not enforced on SET, RESET, and SHOW commandsLimits are not enforced on SET, RESET, and SHOW commands. Additionally, certain queries may be configured to bypass the concurrency limit
External ComponentsManage PL/Container CPU and memory resourcesManage PL/Container CPU resources

Note Disk I/O limits are only available when you use Linux Control Groups v2. See Configuring and Using Resource Groups for more information.

Changes to Resource Groups Attributes

You may configure four new resource group attributes using the CREATE RESOURCE GROUP and ALTER RESOURCE GROUP SQL commands:

  • CPU_MAX_PERCENT, which configures the maximum amount of CPU resources the resource group can use.
  • CPU_WEIGHT, which configures the scheduling priority of the resource group.
  • MIN_COST, which configures the minimum amount a query's query plan cost for the query to remain in the resource group.
  • IO_LIMIT, which configures device I/O usage at the resource group level to manage the maximum throughput of read/write operations, and the maximum read/write operations per second.

The following resource group attributes have been removed:

  • CPU_RATE_LIMIT
  • MEMORY_AUDITOR
  • MEMORY_SPILL_RATIO
  • MEMORY_SHARED_QUOTA

Changes to Server Configuration Parameters

WarehousePG 7 resource group management introduces the following changes to server configuration parameters:

  • The possible settings for the gp_resource_manager server configuration parameter have changed. They now include the following:

    • none - Configures WarehousePG to not use any resource manager. This is the default.
    • group - Configures WarehousePG to use resource groups and base resource group behavior on the cgroup v1 version of Linux cgroup functionality.
    • group-v2 - Configures WarehousePG to use resource groups and base resource group behavior on the cgroup v2 version of Linux cgroup functionality.
    • queue - Configures WarehousePG to use resource queues.
  • The new server configuration parameter gp_resgroup_memory_query_fixed_mem allows you to override at a session level the fixed amount of memory reserved for all queries in a resource group.

  • The new server configuration parameter gp_resource_group_move_timeout cancels the pg_resgroup_move_query() function, which moves a running query from one resouce group to another, if it waits longer than the specified number of miliseconds.

  • The new server configuration parameter gp_resource_group_bypass_direct_dispatch bypasses the resource group's limits for a direct dispatch query so it can run immediately. A direct dispatch query is a special type of query that only requires a single segment to participate in the execution.

  • The server configuration parameter gp_resource_group_cpu_ceiling_enforcement has been removed.

  • The server configuration parameter gp_resource_group_enable_recalculate_query_mem has been removed.

  • The server configuration parameter gp_resource_group_memory_limit has been removed.

Changes to System Views

The following system views have changes:

  • The fields cpu_rate_limit, memory_shared_quota, memory_spill_ratio, and memory_auditor have been replaced by cpu_max_percent, cpu_weight, cpuset, min_cost, and io_limit in the gp_resgroups_config system view.
  • The field rsgname has been renamed to groupname in the gp_resgroup_status system view.
  • The fields cpu_usage and memory_usage have been removed from the gp_resgroup_status system view to the gp_resgroup_status_per_host system view.
  • The fields hostname, cpu, memory_used, memory_available, memory_quota_used, memory_quota_available, memory_shared_used, and memory_shared_available have been removed from the system view gp_resgroup_status_per_host. The fields segment_id, cpu_usage and memory_usage have been added to the view.
  • The fields rsgname, hostname, cpu, memory_used, memory_available, memory_quota_used, memory_quota_available, memory_shared_used, and memory_shared_available have been removed from the system view gp_resgroup_status_per_segment. The fields groupname, and vmem_usage have been added to the view.
  • The gp_resgroup_iostats_per_host system view has been added.