我想将IP路由表信息加入到IP whois信息中。我使用的是亚马逊的RDS，这意味着我无法使用Postgres ip4r扩展程序，因此我使用int8range类型来表示IP地址范围， gist索引。
我的表格如下：
=> \d routing_details
Table "public.routing_details"
Column | Type | Modifiers
----------+-----------+-----------
asn | text |
netblock | text |
range | int8range |
Indexes:
"idx_routing_details_netblock" btree (netblock)
"idx_routing_details_range" gist (range)
=> \d netblock_details
Table "public.netblock_details"
Column | Type | Modifiers
------------+-----------+-----------
range | int8range |
name | text |
country | text |
source | text |
Indexes:
"idx_netblock_details_range" gist (range)
完整的routing_details表包含不到600K行，netblock_details包含大约8.25M行。两个表中都有重叠的范围，但是对于routing_details表中的每个范围，我想从netblock_details表中获得单个最佳（最小）匹配。
我提出了2个不同的查询，我认为这些查询将返回准确的数据，一个使用窗口函数，另一个使用DISTINCT ON：
EXPLAIN SELECT DISTINCT ON (r.netblock) *
FROM routing_details r JOIN netblock_details n ON r.range <@ n.range
ORDER BY r.netblock, upper(n.range) - lower(n.range);
QUERY PLAN
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Unique (cost=118452809778.47..118477166326.22 rows=581300 width=91)
Output: r.asn, r.netblock, r.range, n.range, n.name, n.country, r.netblock, ((upper(n.range) - lower(n.range)))
-> Sort (cost=118452809778.47..118464988052.34 rows=4871309551 width=91)
Output: r.asn, r.netblock, r.range, n.range, n.name, n.country, r.netblock, ((upper(n.range) - lower(n.range)))
Sort Key: r.netblock, ((upper(n.range) - lower(n.range)))
-> Nested Loop (cost=0.00..115920727265.53 rows=4871309551 width=91)
Output: r.asn, r.netblock, r.range, n.range, n.name, n.country, r.netblock, (upper(n.range) - lower(n.range))
Join Filter: (r.range <@ n.range)
-> Seq Scan on public.routing_details r (cost=0.00..11458.96 rows=592496 width=43)
Output: r.asn, r.netblock, r.range
-> Materialize (cost=0.00..277082.12 rows=8221675 width=48)
Output: n.range, n.name, n.country
-> Seq Scan on public.netblock_details n (cost=0.00..163712.75 rows=8221675 width=48)
Output: n.range, n.name, n.country
(14 rows) -> Seq Scan on netblock_details n (cost=0.00..163712.75 rows=8221675 width=48)
EXPLAIN VERBOSE SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY r.range ORDER BY UPPER(n.range) - LOWER(n.range)) AS rank
FROM routing_details r JOIN netblock_details n ON r.range <@ n.range
) a WHERE rank = 1 ORDER BY netblock;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=118620775630.16..118620836521.53 rows=24356548 width=99)
Output: a.asn, a.netblock, a.range, a.range_1, a.name, a.country, a.rank
Sort Key: a.netblock
-> Subquery Scan on a (cost=118416274956.83..118611127338.87 rows=24356548 width=99)
Output: a.asn, a.netblock, a.range, a.range_1, a.name, a.country, a.rank
Filter: (a.rank = 1)
-> WindowAgg (cost=118416274956.83..118550235969.49 rows=4871309551 width=91)
Output: r.asn, r.netblock, r.range, n.range, n.name, n.country, row_number() OVER (?), ((upper(n.range) - lower(n.range))), r.range
-> Sort (cost=118416274956.83..118428453230.71 rows=4871309551 width=91)
Output: ((upper(n.range) - lower(n.range))), r.range, r.asn, r.netblock, n.range, n.name, n.country
Sort Key: r.range, ((upper(n.range) - lower(n.range)))
-> Nested Loop (cost=0.00..115884192443.90 rows=4871309551 width=91)
Output: (upper(n.range) - lower(n.range)), r.range, r.asn, r.netblock, n.range, n.name, n.country
Join Filter: (r.range <@ n.range)
-> Seq Scan on public.routing_details r (cost=0.00..11458.96 rows=592496 width=43)
Output: r.asn, r.netblock, r.range
-> Materialize (cost=0.00..277082.12 rows=8221675 width=48)
Output: n.range, n.name, n.country
-> Seq Scan on public.netblock_details n (cost=0.00..163712.75 rows=8221675 width=48)
Output: n.range, n.name, n.country
(20 rows)
DISTINCT ON看起来效率稍高，所以我继续使用那个。当我针对完整数据集运行查询时，在大约24小时等待之后，我得到了磁盘空间不足的错误。我创建了一个routing_details_small表，其中包含完整routing_details表的N行子集，以尝试了解正在进行的操作。
N = 1000
=> EXPLAIN ANALYZE SELECT DISTINCT ON (r.netblock) *
-> FROM routing_details_small r JOIN netblock_details n ON r.range <@ n.range
-> ORDER BY r.netblock, upper(n.range) - lower(n.range);
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Unique (cost=4411888.68..4453012.20 rows=999 width=90) (actual time=124.094..133.720 rows=999 loops=1)
-> Sort (cost=4411888.68..4432450.44 rows=8224705 width=90) (actual time=124.091..128.560 rows=4172 loops=1)
Sort Key: r.netblock, ((upper(n.range) - lower(n.range)))
Sort Method: external sort Disk: 608kB
-> Nested Loop (cost=0.41..1780498.29 rows=8224705 width=90) (actual time=0.080..101.518 rows=4172 loops=1)
-> Seq Scan on routing_details_small r (cost=0.00..20.00 rows=1000 width=42) (actual time=0.007..1.037 rows=1000 loops=1)
-> Index Scan using idx_netblock_details_range on netblock_details n (cost=0.41..1307.55 rows=41124 width=48) (actual time=0.063..0.089 rows=4 loops=1000)
Index Cond: (r.range <@ range)
Total runtime: 134.999 ms
(9 rows)
N = 100000
=> EXPLAIN ANALYZE SELECT DISTINCT ON (r.netblock) *
-> FROM routing_details_small r JOIN netblock_details n ON r.range <@ n.range
-> ORDER BY r.netblock, upper(n.range) - lower(n.range);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Unique (cost=654922588.98..659034941.48 rows=200 width=144) (actual time=28252.677..29487.380 rows=98992 loops=1)
-> Sort (cost=654922588.98..656978765.23 rows=822470500 width=144) (actual time=28252.673..28926.703 rows=454856 loops=1)
Sort Key: r.netblock, ((upper(n.range) - lower(n.range)))
Sort Method: external merge Disk: 64488kB
-> Nested Loop (cost=0.41..119890431.75 rows=822470500 width=144) (actual time=0.079..24951.038 rows=454856 loops=1)
-> Seq Scan on routing_details_small r (cost=0.00..1935.00 rows=100000 width=96) (actual time=0.007..110.457 rows=100000 loops=1)
-> Index Scan using idx_netblock_details_range on netblock_details n (cost=0.41..725.96 rows=41124 width=48) (actual time=0.067..0.235 rows=5 loops=100000)
Index Cond: (r.range <@ range)
Total runtime: 29596.667 ms
(9 rows)
N = 250000
=> EXPLAIN ANALYZE SELECT DISTINCT ON (r.netblock) *
-> FROM routing_details_small r JOIN netblock_details n ON r.range <@ n.range
-> ORDER BY r.netblock, upper(n.range) - lower(n.range);
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Unique (cost=1651822953.55..1662103834.80 rows=200 width=144) (actual time=185835.443..190143.266 rows=247655 loops=1)
-> Sort (cost=1651822953.55..1656963394.18 rows=2056176250 width=144) (actual time=185835.439..188779.279 rows=1103850 loops=1)
Sort Key: r.netblock, ((upper(n.range) - lower(n.range)))
Sort Method: external merge Disk: 155288kB
-> Nested Loop (cost=0.28..300651962.46 rows=2056176250 width=144) (actual time=19.325..177403.913 rows=1103850 loops=1)
-> Seq Scan on netblock_details n (cost=0.00..163743.05 rows=8224705 width=48) (actual time=0.007..8160.346 rows=8224705 loops=1)
-> Index Scan using idx_routing_details_small_range on routing_details_small r (cost=0.28..22.16 rows=1250 width=96) (actual time=0.018..0.018 rows=0 loops=8224705)
Index Cond: (range <@ n.range)
Total runtime: 190413.912 ms
(9 rows)
对于具有600k行的完整表，查询在大约24小时后失败，并且出现磁盘空间不足的错误，这可能是由外部合并步骤引起的。因此，使用一个小的routing_details表，这个查询运行良好且非常快，但扩展性很差。
有关如何改进我的查询或甚至是模式更改的建议我可以使这个查询在整个数据集上有效工作？
答案 0 :(得分：3)
我没有给你很好的答案，因为我不熟悉gist索引，但我有点兴趣，所以我看了一下你的解释计划。有几件事情脱颖而出：
1）您的计划使用嵌套循环连接，即使在250K示例中也是如此。它是seq扫描较大的表，并在较小的表上进行查找。这意味着它在较小的表上进行了800万次索引查找，占用时间超过148秒。我很奇怪，随着routing_details_small表的大小增加，这种情况会显着减慢。就像我说的，我不熟悉gist索引，但我会试验set enable_nestloop to false;，看看你是否可以让它做某种排序的合并/散列连接。
2）最后正在执行distinct。这需要相当一部分时间（约11秒），但这也意味着你可能会做一些额外的工作。它看起来像独特的结果数量从100多万减少到250K，所以我会尝试更早地尝试。我不确定您是否收到重复项，因为routing_details_small表中有netblock表中有多个条目，或者netblock_details表对于给定的网络块有多个匹配项。如果是前者，您可以加入仅具有唯一路由详细信息的子查询。如果是后者，试试我要提到的事情：
3）稍微结合前两个观察结果，您可以尝试从routing_details_small上的seq扫描中进行部分连接（连接子查询）。这应该只导致600K索引扫描。像（假设postgres 9.4）：
SELECT * FROM routing_details_small r,
LATERAL (SELECT * FROM netblock_details n WHERE r.range <@ n.range LIMIT 1) nb;
答案 1 :(得分：3)
我最初想的是横向连接，就像其他建议的方法一样（例如，Erwin Brandstetter的最后一个查询，他使用简单的int8数据类型和简单的索引），但并不想把它写在答案中，因为我认为它不是真的有效。当您尝试查找涵盖给定范围的所有netblock范围时，索引并没有多大帮助。
我将在此重复Erwin Brandstetter的询问：
SELECT * -- only select columns you need to make it faster
FROM routing_details r
, LATERAL (
SELECT *
FROM netblock_details n
WHERE n.ip_min <= r.ip_min
AND n.ip_max >= r.ip_max
ORDER BY n.ip_max - n.ip_min
LIMIT 1
) n;
当您在netblock_details上有索引时，如下所示：
CREATE INDEX netblock_details_ip_min_max_idx ON netblock_details
(ip_min, ip_max DESC NULLS LAST);
您可以快速（O(logN)）在netblock_details表格中找到扫描的起点 - 最小n.ip_min小于r.ip_min，或者最低n.ip_max超过r.ip_max。但是你必须扫描/读取索引/表的其余部分，并且每行检查的第二部分并过滤掉大多数行。
换句话说，此索引有助于快速找到满足第一个搜索条件的起始行：n.ip_min <= r.ip_min，但随后您将继续读取满足此条件的所有行，并且对于每个此类行执行第二次检查n.ip_max >= r.ip_max。平均而言（如果数据均匀分布），您必须阅读netblock_details表的一半行。优化工具可以选择使用索引首先搜索n.ip_max >= r.ip_max，然后应用第二个过滤器n.ip_min <= r.ip_min，但您无法使用此索引将两个过滤器同时应用。
最终结果：
对于routing_details中的每一行，我们将从netblock_details读取一半行。 600K * 4M = 2,400,000,000,000行。
它比笛卡儿产品好2倍。您可以在问题的EXPLAIN ANALYZE输出中看到此编号（笛卡尔积）。
592,496 * 8,221,675 = 4,871,309,550,800
难怪在尝试实现和排序时，您的查询会耗尽磁盘空间。
达到最终结果的整体高级流程：
加入两个表（尚未找到最佳匹配）。在最坏的情况下，它是笛卡尔积，在最好的情况下，对于netblock_details的每个范围，所有覆盖范围均为routing_details。您说netblock_details中routing_details中的每个条目都有多个条目，从3到10左右。因此，此连接的结果可能有~6M行（不太多）
按routing_details范围对联接结果进行排序/分区，并且每个此类范围都会找到netblock_details的最佳（最小）覆盖范围。
我的想法是颠倒查询。我建议不要从较小的netblock_details表中找到每行较大routing_details的所有覆盖范围，而是从较大routing_details的每一行中找到较小netblock_details的较小范围。< / p>
两步流程
对于较大netblock_details的每一行，查找routing_details范围内netblock范围内的所有范围。
我会在查询中使用以下架构。我已将主键ID添加到两个表中。
CREATE TABLE routing_details (
ID int
,ip_min int8
,ip_max int8
,asn text
,netblock text
);
CREATE TABLE netblock_details (
ID int
,ip_min int8
,ip_max int8
,name text
,country text
,source text
);
SELECT
netblock_details.ID AS n_ID
,netblock_details.ip_max - netblock_details.ip_min AS n_length
,r.ID AS r_ID
FROM
netblock_details
INNER JOIN LATERAL
(
SELECT routing_details.ID
FROM routing_details
WHERE
routing_details.ip_min >= netblock_details.ip_min
AND routing_details.ip_min <= netblock_details.ip_max
-- note how routing_details.ip_min is limited from both sides
-- this would make it possible to scan only (hopefully) small
-- portion of the table instead of full or half table
AND routing_details.ip_max <= netblock_details.ip_max
-- this clause ensures that the whole routing range
-- is inside the netblock range
) AS r ON true
我们需要routing_details上(ip_min, ip_max)的索引。这里的主要内容是ip_min上的索引。在索引中包含第二列有助于消除对ip_max的值进行查找的需要;它在树搜索中没有帮助。
请注意，横向子查询没有LIMIT。这还不是最终的结果。此查询应返回~6M行。将此结果保存在临时表中。
在(r_ID, n_length, n_ID)上的临时表中添加索引。 n_ID只是删除额外的查找。我们需要一个索引来避免为每个r_ID排序数据。
最后一步
对于routing_details中的每一行，找到n_ID最小的n_length。现在我们可以在＆＃34;中使用横向连接＆＃34;订购。此处temp表格是上一步的索引的结果。
SELECT
routing_details.*
,t.n_ID
,netblock_details.*
FROM
routing_details
INNER JOIN LATERAL
(
SELECT temp.n_ID
FROM temp
WHERE temp.r_ID = routing_details.ID
ORDER BY temp.n_length
LIMIT 1
) AS t ON true
INNER JOIN netblock_details ON netblock_details.ID = t.n_ID
这里的子查询应该是索引的搜索，而不是扫描。优化器应该足够智能，只需查找并返回由于LIMIT 1而找到的第一个结果，因此您将在6M行临时表中搜索600K索引。
原始答案（我只保留范围图表）：
你能＆＃34;作弊＆＃34;？
如果我正确理解了您的查询，则每个routing_details.range
您希望找到覆盖/大于netblock_details.range的最小routing_details.range。
鉴于以下示例，其中r是路由范围且n1, ..., n8是网络范围，正确答案为n5。
|---|
n1
|------------------|
n2
|---------------|
n3
|-----|
n4
|------------------|
n5
|--------------------------------------|
n6
|---------------------------|
n7
|-----|
n8
|------------|
r
start end
n.start <= r.start AND n.end >= r.end
order by n.length
limit 1
您的query that took 14 hours显示索引扫描花了6毫秒，但按范围长度排序需要80毫秒。
通过这种搜索，数据没有简单的一维排序。您将n.start与n.end一起使用，并与n.length一起使用。但是，也许您的数据不是通用的，或者可以返回稍微不同的结果。
例如，如果可以返回n6，那么它可以更快地运行。 n6是覆盖范围最大的start：
n.start <= r.start AND n.end >= r.end
order by n.start desc
limit 1
或者，您可以选择n7，end：
n.start <= r.start AND n.end >= r.end
order by n.end
limit 1
这种搜索会在n.start（或n.end）上使用简单索引而无需额外排序。
第二种，完全不同的方法。范围有多大/多长？如果它们相对较短（数字很少），那么您可以尝试将它们存储为显式的整数列表，而不是范围。
例如，范围[5-8]将存储为4行：(5, 6, 7, 8)。使用此存储模型，可以更容易地找到范围的交叉点。
答案 2 :(得分：2)
使用 LATERAL加入（查找routing_details中每行的最小匹配项）：
这些查询的唯一相关索引是：
"idx_netblock_details_range" gist (range)
其他指数在这里无关紧要。
SELECT * -- only select columns you need to make it faster
FROM routing_details r
, LATERAL (
SELECT *
FROM netblock_details n
WHERE n.range @> r.range
ORDER BY upper(n.range) - lower(n.range)
LIMIT 1
) n
SQL Fiddle包含更真实的测试数据。
与原始查询一样，routing_details中netblock_details没有任何匹配的行会从结果中删除。
性能取决于数据分布。这应该是很多匹配的优势。 DISTINCT ON中每行只有极少数匹配可能会赢得routing_details - 但是对于大类，它需要很多 work_mem。为大查询提供大约200 MB的空间。在同一交易中使用SET LOCAL：
此查询 不需要尽可能多的排序内存。与DISTINCT ON不同，你不应该看到Postgres交换到磁盘进行排序，而work_mem的设置中等。所以在EXPLAIN ANALYZE输出中没有这样的行：
<击> Sort Method: external merge Disk: 155288kB
再看一下，我测试了一个简单的设计，其中包含用于下限和上限的普通int8列而不是范围类型和一个简单的btree索引：
CREATE TABLE routing_details ( -- SMALL table
ip_min int8
, ip_max int8
, asn text
, netblock text
);
CREATE TABLE netblock_details ( -- BIG table
ip_min int8
, ip_max int8
, name text
, country text
, source text
);
CREATE INDEX netblock_details_ip_min_max_idx ON netblock_details
(ip_min, ip_max DESC NULLS LAST);
排序第二个索引列DESC NULLS LAST至关重要！
SELECT * -- only select columns you need to make it faster
FROM routing_details r
, LATERAL (
SELECT *
FROM netblock_details n
WHERE n.ip_min <= r.ip_min
AND n.ip_max >= r.ip_max
ORDER BY n.ip_max - n.ip_min
LIMIT 1
) n;
相同的基本技术。在我的测试中，这比第一种方法快约3倍。但对于数百万行仍然不够快。
该技术的详细说明（带有b-tree索引的示例，但GiST索引的查询原理类似）：
对于DISTINCT ON变体：
上述解决方案与routing_details中的行数呈线性关系，但随着netblock_details中的匹配数而恶化。它最终回到我身边：我们在dba.SE上 解决了这个问题 ，采用更复杂的方法，产生了很大的优势：
frequency在此处扮演ip_max - n.ip_min / upper(range) - lower(range)的角色。
答案 3 :(得分：1)
我不知道这是否对真实数据有效。候选人选择被挤入内循环，这对我来说似乎很好。在测试时，它给出了两个索引扫描（加上一个用于反连接），避免了最终的排序/唯一。它确实似乎给出了相同的结果。
-- EXPLAIN ANALYZE
SELECT *
FROM routing_details r
JOIN netblock_details n ON r.range <@ n.range
-- We want the smallest overlapping range
-- Use "Not exists" to suppress overlapping ranges
-- that are larger than n
-- (this should cause an antijoin)
WHERE NOT EXISTS(
SELECT * FROM netblock_details nx
WHERE r.range <@ nx.range -- should enclose r
AND n.range <> nx.range -- but differ from n
AND (nx.range <@ n.range -- and overlap n, or be larger
OR upper(nx.range) - lower(nx.range) < upper(n.range) - lower(n.range)
OR (upper(nx.range) - lower(nx.range) = upper(n.range) - lower(n.range) AND lower(nx.range) > lower(n.range) )
)
)
ORDER BY r.netblock
-- not needed any more
-- , upper(n.range) - lower(n.range)
;
更新：（FWIW）作为奖金，我的测试数据集
CREATE Table routing_details
( asn text
, netblock text
, range int8range
);
-- Indexes:
CREATE INDEX idx_routing_details_netblock ON routing_details (netblock);
CREATE INDEX idx_routing_details_range ON routing_details USING gist(range) ;
CREATE Table netblock_details
( range int8range
, name text
, country text
, source text
);
-- Indexes:
CREATE INDEX idx_netblock_details_range ON netblock_details USING gist(range);
-- the smaller table
INSERT INTO routing_details(range,netblock)
SELECT int8range(gs, gs+13), 'block_' || gs::text
FROM generate_series(0,1000000, 11) gs
;
-- the larger table
INSERT INTO netblock_details(range,name)
SELECT int8range(gs, gs+17), 'name_' || gs::text
FROM generate_series(0,1000000, 17) gs
;
INSERT INTO netblock_details(range,name)
SELECT int8range(gs, gs+19), 'name_' || gs::text
FROM generate_series(0,1000000, 19) gs
;
INSERT INTO netblock_details(range,name)
SELECT int8range(gs, gs+23), 'name_' || gs::text
FROM generate_series(0,1000000, 23) gs
;
VACUUM ANALYZE routing_details;
VACUUM ANALYZE netblock_details;