如何构造 SQL - 为列的每个值选择前 X 行？

Question

我有一个包含以下类型数据的表：

create table store (
    n_id             serial not null primary key,
    n_place_id       integer not null references place(n_id),
    dt_modified      timestamp not null,
    t_tag            varchar(4),
    n_status         integer not null default 0
    ...
    (about 50 more fields)
);

在下面的查询中使用的 n_id、n_place_id、dt_modified 和所有其他字段都有索引。

此表目前包含大约 100,000 行，但可能会增长到接近一百万甚至更多。然而，现在让我们假设我们保持在 100K 左右。

我正在尝试从这些表中选择满足一个两个条件的行：

1. n_place_id 在特定子集中的所有行（这部分很简单）；或
2. 对于所有其他n_place_id 值，前十行按dt_modified 排序（这会变得更加复杂）。

在一个 SQL 中执行此操作似乎太痛苦了，因此我对为此使用存储函数感到满意。我的函数是这样定义的：

create or replace function api2.fn_api_mobile_objects()
  returns setof store as
$body$
declare
    maxres_free integer := 10;
    resulter    store%rowtype;
    mcnt        integer := 0;
    previd      integer := 0;
begin
    create temporary table paid on commit drop as
    select n_place_id from payments where t_reference is not null and now()::date between dt_paid and dt_valid;

    for resulter in
        select * from store where n_status > 0 and t_tag is not null order by n_place_id, dt_modified desc
    loop
        if resulter.n_place_id in (select n_place_id from paid) then
            return next resulter;
        else
            if previd <> resulter.n_place_id then
                mcnt := 0;
                previd := resulter.n_place_id;
            end if;

            if mcnt < maxres_free then
                return next resulter;
                mcnt := mcnt + 1;
            end if;
        end if;
    end loop;
end;$body$
  language 'plpgsql' volatile;

问题是

select * from api2.fn_api_mobile_objects()

执行大约需要 6-7 秒。考虑到在那之后这个结果集需要joined 到其他 3 个表，并应用了一堆附加条件并应用了进一步的排序，这显然是不可接受的。

好吧，我仍然需要获取这些数据，所以要么我在函数中遗漏了一些东西，要么我需要重新考虑整个算法。不管怎样，我需要这方面的帮助。

Answer 1

CREATE TABLE store
    ( n_id             serial not null primary key
    , n_place_id       integer not null -- references place(n_id)
    , dt_modified      timestamp not null
    , t_tag            varchar(4)
    , n_status         integer not null default 0
        );
INSERT INTO store(n_place_id,dt_modified,n_status)
SELECT n,d,n%4
FROM generate_series(1,100) n
, generate_series('2012-01-01'::date ,'2012-10-01'::date, '1 day'::interval ) d
        ;

WITH zzz AS (
        SELECT n_id AS n_id
        , rank() OVER (partition BY n_place_id ORDER BY dt_modified) AS rnk
        FROM store
        )
SELECT st.*
FROM store st
JOIN zzz ON zzz.n_id = st.n_id
WHERE st.n_place_id IN ( 1,22,333)
OR zzz.rnk <=10
        ;

更新：这里是与子查询相同的 selfjoin 构造（CTE 被规划器处理有点不同）：

SELECT st.*
FROM store st
JOIN ( SELECT sx.n_id AS n_id
        , rank() OVER (partition BY sx.n_place_id ORDER BY sx.dt_modified) AS zrnk
        FROM store sx
        ) xxx ON xxx.n_id = st.n_id
WHERE st.n_place_id IN ( 1,22,333)
OR xxx.zrnk <=10
        ;

Answer 2

经过一番努力，我设法让存储函数在 1 秒多的时间内返回结果（这是一个巨大的改进）。现在函数看起来是这样的（我添加了附加条件，对性能影响不大）：

create or replace function api2.fn_api_mobile_objects(t_search varchar)
  returns setof store as
$body$
declare
    maxres_free integer := 10;
    resulter    store%rowtype;
    mid     integer := 0;
begin
    create temporary table paid on commit drop as
    select n_place_id from payments where t_reference is not null and now()::date between dt_paid and dt_valid
    union
    select n_place_id from store where n_status > 0 and t_tag is not null group by n_place_id having count(1) <= 10;

    for resulter in
        select * from store
        where n_status > 0 and t_tag is not null
        and (t_name ~* t_search or t_description ~* t_search)
        and n_place_id in (select n_place_id from paid)
    loop
        return next resulter;
    end loop;

    for mid in
        select distinct n_place_id from store where n_place_id not in (select n_place_id from paid)
    loop
        for resulter in
            select * from store where n_status > 0 and t_tag is not null and n_place_id = mid order by dt_modified desc limit maxres_free
        loop
            return next resulter;
        end loop;
    end loop;

end;$body$
  language 'plpgsql' volatile;

这在我的本地机器上运行只需 1 秒多一点，而在现场运行大约需要 0.8-1.0 秒。就我的目的而言，这已经足够了，尽管我不确定随着数据量的增长会发生什么。

Answer 3

作为一个简单的建议，我喜欢进行此类故障排除的方式是构建一个查询，使我能够顺利完成大部分任务，并对其进行适当优化，然后在其周围添加必要的 pl/pgsql 内容。这种方法的主要优点是您可以根据查询计划进行优化。

此外，如果您不处理大量行，array_agg() 和 unnest() 是您的朋友，因为它们允许您（在 Pg 8.4 及更高版本上！）省去临时表管理开销并简单地构造和查询内存中的元组数组作为关系。如果您只是在内存中访问数组而不是临时表，它也可能会执行得更好（更少的计划开销和更少的查询开销）。

此外，在您更新后的查询中，我会考虑用子查询或连接替换最终循环，从而允许规划器决定何时进行嵌套循环查找或何时尝试找到更好的方法。