PostgreSQL - “IN”子句中的最大参数数量?

时间:2009-06-17 21:48:13

标签: postgresql

在Postgres中,您可以指定一个IN子句,如下所示:

SELECT * FROM user WHERE id IN (1000, 1001, 1002)

有谁知道你可以传入IN的最大参数数量是什么?

8 个答案:

答案 0 :(得分:72)

根据位于here, starting at line 850,的源代码,PostgreSQL没有明确限制参数的数量。

以下是第870行的代码注释:

/*
 * We try to generate a ScalarArrayOpExpr from IN/NOT IN, but this is only
 * possible if the inputs are all scalars (no RowExprs) and there is a
 * suitable array type available.  If not, we fall back to a boolean
 * condition tree with multiple copies of the lefthand expression.
 * Also, any IN-list items that contain Vars are handled as separate
 * boolean conditions, because that gives the planner more scope for
 * optimization on such clauses.
 *
 * First step: transform all the inputs, and detect whether any are
 * RowExprs or contain Vars.
 */

答案 1 :(得分:42)

这不是对当前问题的真正答案,但它也可能对其他人有所帮助。

至少我可以说使用Posgresql的JDBC驱动程序9.1,可以将32767个值(= Short.MAX_VALUE)的技术限制传递给PostgreSQL后端。

这是"从x中删除的测试,其中id为(... 100k值...)"使用postgresql jdbc驱动程序:

Caused by: java.io.IOException: Tried to send an out-of-range integer as a 2-byte value: 100000
    at org.postgresql.core.PGStream.SendInteger2(PGStream.java:201)

答案 2 :(得分:34)

explain select * from test where id in (values (1), (2));

查询计划

 Seq Scan on test  (cost=0.00..1.38 rows=2 width=208)
   Filter: (id = ANY ('{1,2}'::bigint[]))

但是如果尝试第二次查询:

explain select * from test where id = any (values (1), (2));

查询计划

Hash Semi Join  (cost=0.05..1.45 rows=2 width=208)
       Hash Cond: (test.id = "*VALUES*".column1)
       ->  Seq Scan on test  (cost=0.00..1.30 rows=30 width=208)
       ->  Hash  (cost=0.03..0.03 rows=2 width=4)
             ->  Values Scan on "*VALUES*"  (cost=0.00..0.03 rows=2 width=4)

我们可以看到postgres构建临时表并加入它

答案 3 :(得分:16)

传递给IN子句的元素数量没有限制。如果有更多元素,它会将其视为数组,然后对于数据库中的每次扫描,它将检查它是否包含在数组中。这种方法不具备可扩展性。而不是使用IN子句尝试使用INNER JOIN与临时表。有关详细信息,请参阅http://www.xaprb.com/blog/2006/06/28/why-large-in-clauses-are-problematic/。使用INNER JOIN可以很好地扩展,因为查询优化器可以使用散列连接和其他优化。而使用IN子句,优化器无法优化查询。我注意到这个改变至少加速了2倍。

答案 4 :(得分:11)

作为对Oracle DB更有经验的人,我也担心这个限制。我在IN列表中对~10'000个参数的查询进行了性能测试,通过实际列出所有参数,从具有前100'000个整数的表中获取高达100'000的素数素数作为查询参数

我的结果表明您不必担心重载查询计划优化器或获取没有索引使用的计划,因为它会将查询转换为使用= ANY({...}::integer[]),因为它可以将索引用作预期:

-- prepare statement, runs instantaneous:
PREPARE hugeplan (integer, integer, integer, ...) AS
SELECT *
FROM primes
WHERE n IN ($1, $2, $3, ..., $9592);

-- fetch the prime numbers:
EXECUTE hugeplan(2, 3, 5, ..., 99991);

-- EXPLAIN ANALYZE output for the EXECUTE:
"Index Scan using n_idx on primes  (cost=0.42..9750.77 rows=9592 width=5) (actual time=0.024..15.268 rows=9592 loops=1)"
"  Index Cond: (n = ANY ('{2,3,5,7, (...)"
"Execution time: 16.063 ms"

-- setup, should you care:
CREATE TABLE public.primes
(
  n integer NOT NULL,
  prime boolean,
  CONSTRAINT n_idx PRIMARY KEY (n)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.primes
  OWNER TO postgres;

INSERT INTO public.primes
SELECT generate_series(1,100000);

答案 5 :(得分:2)

尝试一下。答案是-> 超出范围的整数(2字节值):32768

答案 6 :(得分:1)

您可能需要考虑重构该查询,而不是添加任意长的ID列表...如果ID确实遵循示例中的模式,则可以使用范围:

SELECT * FROM user WHERE id >= minValue AND id <= maxValue;

另一个选择是添加内部选择:

SELECT * 
FROM user 
WHERE id IN (
    SELECT userId
    FROM ForumThreads ft
    WHERE ft.id = X
);

答案 7 :(得分:1)

如果您有以下查询:

SELECT * FROM user WHERE id IN (1, 2, 3, 4 -- and thousands of another keys)

您可以提高重写查询的效果,如:

SELECT * FROM user WHERE id = ANY(VALUES (1), (2), (3), (4) -- and thousands of another keys)