Amazon Redshift
数据库开发人员指南 (API Version 2012-12-01)
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。点 击 Getting Started with Amazon AWS to see specific differences applicable to the China (Beijing) Region.

第 4 节:使用 wlm_query_slot_count 临时覆盖队列中的并发级别

有时,用户可能会为某个特定查询临时需要更多资源。如果是这样的话,他们可以使用 wlm_query_slot_count 配置设置来临时覆盖查询队列中分配槽位的方式。槽位 是用于处理查询的内存和 CPU 的单位。您可在偶尔使用消耗集群中大量资源的查询时(例如,在数据库中执行 VACUUM 操作时)覆盖槽位计数。

如果您发现用户经常需要针对特定类型的查询设置 wlm_query_slot_count,则您应考虑调整 WLM 配置并为用户提供更适合其查询需求的队列。有关通过使用槽位计数临时覆盖并发级别的更多信息,请参阅wlm_query_slot_count

步骤 1:使用 wlm_query_slot_count 覆盖并发级别

在本教程中,我们将运行同一个长时间运行的 SELECT 查询。我们将以 adminwlm 用户的身份运行查询,并使用 wlm_query_slot_count 增加查询的可用槽位数。

使用 wlm_query_slot_count 覆盖并发级别

  1. 提高对查询的限制以确保您有足够的时间来查询 WLM_QUERY_STATE_VW 视图并查看结果。

    Copy
    set wlm_query_slot_count to 3; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  2. 现在,查询 WLM_QUERY_STATE_VW 将使用 masteruser 账户来查看查询运行的方式。

    Copy
    select * from wlm_query_state_vw;

    下面是示例结果。

    请注意,查询的槽位计数是 3。此计数表示查询正在使用所有三个槽位来处理查询,并将队列中的所有资源分配给查询。

  3. 现在,运行以下查询。

    Copy
    select * from WLM_QUEUE_STATE_VW;

    下面是示例结果。

    wlm_query_slot_count 配置设置仅对当前会话有效。如果会话过期或者另一用户运行查询,则使用 WLM 配置。

  4. 重置槽位计数并重新运行测试。

    Copy
    reset wlm_query_slot_count; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;

    以下是示例结果。

步骤 2:从不同会话中运行查询

接下来,从不同会话中运行查询。

从不同会话中运行查询

  1. 在 psql 窗口 1 和 2 中,运行以下查询以使用 test 查询组。

    Copy
    set query_group to test;
  2. 在 psql 窗口 1 中,运行以下长时间运行的查询。

    Copy
    select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  3. 由于此长时间运行的查询仍在 psql 窗口 1 中运行,请运行以下查询来增加槽位计数,从而使用队列的全部槽位并开始运行长时间运行的查询。

    Copy
    set wlm_query_slot_count to 2; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  4. 打开第三个 psql 窗口并查询视图以查看结果。

    Copy
    select * from wlm_queue_state_vw; select * from wlm_query_state_vw;

    以下是示例结果。

    请注意,第一个查询正在使用分配给队列 1 的槽位之一来运行查询,而且还有一个查询正在该队列中等待(其中,queued1stateQueuedWaiting)。在第一个查询完成之后,第二个查询即会开始执行。此执行发生的原因在于:两个查询均已路由至 test 查询组,而且第二个查询必须等待有足够多的槽位才能开始进行处理。