4

我们在项目中使用 PostgREST 来处理一些相当复杂的数据库视图。

从某些时候开始，当我们使用限制和偏移（x 范围标头或查询参数）和子选择时，我们会得到非常长的响应时间。

从我们所读到的内容来看，这似乎是一个已知问题，postgresql 即使对未请求的记录也执行子选择。解决方案是稍微调整偏移量和限制，将其放入子选择或 CTE 表中。

我们可以在数据库视图中使用内部 GUC 值或类似的值来优化响应时间吗？有没有人暗示如何实现这一目标？

编辑：这里建议有更多细节。假设我们在产品和零件之间有关系。我想知道每个产品的零件数量（这是我们公开的数据库视图的简化版本）。

有两种方法可以做到这一点

A. 子选择：

    SELECT products.id
            ,(
                    SELECT count(part_id) AS total
                    FROM parts
                    WHERE product_id = products.id
                    )
    FROM products limit 1000 OFFSET 99000

B. CTE：

    WITH parts_count
    AS (
            SELECT product_id
                    ,count(part_id) AS total
            FROM parts
            GROUP BY product_id
            ORDER BY product_id
            )
    SELECT products.id
            ,parts_count.total
    FROM products
    LEFT JOIN parts_count ON parts_count.product_id = product.id 
    LIMIT 1000     
    OFFSET 99000

A的问题是对每一行执行子选择，因此即使我只读取 1000 条记录，也有 100 000 个子选择。

B的问题是与parts_count 表的连接需要很长时间，因为那里有100 0000 条记录（尽管with 查询只需要200 毫秒！对于2000 条记录）。理想情况下，我希望使用与主查询相同的限制和偏移量来限制parts_count 表，但我不能在 PostgREST 中执行此操作，因为它只是在末尾附加限制和偏移量，我无权访问里面的那些参数WITH查询_

4

1 回答 1

4

OFFSET高导致性能差是不可避免的。

OFFSET除了扫描并丢弃所有行，直到达到偏移量，没有其他方法可以计算，并且世界上没有数据库会在OFFSET高时快速。

这是一个概念问题，避免它的唯一方法是避免OFFSET.

如果您的目标是分页，那么通常键集分页是一个更好的解决方案：

您添加一个ORDER BY符合您要求的子句，确保该ORDER BY子句中有一个唯一键并记住您找到的最后一个值。要获取下一页，请添加WHERE具有该值的条件。有了适当的索引支持，这可以非常快。

对于您的查询，更有效的版本可能是：

SELECT p.id
       count(parts.part_id) AS total
FROM (SELECT id FROM products
      LIMIT 1000 OFFSET 99000) p
   LEFT JOIN parts ON parts.product_id = p.id
GROUP BY p.id;

你没有ORDER BY, 但是LIMIT和是相当奇怪的OFFSET。这没有多大意义。

于 2018-05-30T02:52:39.853 回答