1999-02-08 15:14:32 +01:00
|
|
|
--
|
2000-01-06 07:41:55 +01:00
|
|
|
-- LIMIT
|
1999-02-08 15:14:32 +01:00
|
|
|
-- Check the LIMIT/OFFSET feature of SELECT
|
|
|
|
--
|
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS two, unique1, unique2, stringu1
|
|
|
|
FROM onek WHERE unique1 > 50
|
1999-02-08 15:14:32 +01:00
|
|
|
ORDER BY unique1 LIMIT 2;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS five, unique1, unique2, stringu1
|
|
|
|
FROM onek WHERE unique1 > 60
|
1999-02-08 15:14:32 +01:00
|
|
|
ORDER BY unique1 LIMIT 5;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS two, unique1, unique2, stringu1
|
1999-02-08 15:14:32 +01:00
|
|
|
FROM onek WHERE unique1 > 60 AND unique1 < 63
|
|
|
|
ORDER BY unique1 LIMIT 5;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS three, unique1, unique2, stringu1
|
|
|
|
FROM onek WHERE unique1 > 100
|
1999-02-08 15:14:32 +01:00
|
|
|
ORDER BY unique1 LIMIT 3 OFFSET 20;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS zero, unique1, unique2, stringu1
|
|
|
|
FROM onek WHERE unique1 < 50
|
1999-02-08 15:14:32 +01:00
|
|
|
ORDER BY unique1 DESC LIMIT 8 OFFSET 99;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS eleven, unique1, unique2, stringu1
|
|
|
|
FROM onek WHERE unique1 < 50
|
1999-02-08 15:14:32 +01:00
|
|
|
ORDER BY unique1 DESC LIMIT 20 OFFSET 39;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS ten, unique1, unique2, stringu1
|
1999-02-08 15:14:32 +01:00
|
|
|
FROM onek
|
|
|
|
ORDER BY unique1 OFFSET 990;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS five, unique1, unique2, stringu1
|
1999-02-08 15:14:32 +01:00
|
|
|
FROM onek
|
|
|
|
ORDER BY unique1 OFFSET 990 LIMIT 5;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT ''::text AS five, unique1, unique2, stringu1
|
1999-02-08 15:14:32 +01:00
|
|
|
FROM onek
|
2001-10-20 04:55:39 +02:00
|
|
|
ORDER BY unique1 LIMIT 5 OFFSET 900;
|
2007-05-17 21:35:08 +02:00
|
|
|
|
2017-08-11 23:27:54 +02:00
|
|
|
-- Test null limit and offset. The planner would discard a simple null
|
|
|
|
-- constant, so to ensure executor is exercised, do this:
|
|
|
|
select * from int8_tbl limit (case when random() < 0.5 then null::bigint end);
|
|
|
|
select * from int8_tbl offset (case when random() < 0.5 then null::bigint end);
|
|
|
|
|
|
|
|
-- Test assorted cases involving backwards fetch from a LIMIT plan node
|
|
|
|
begin;
|
|
|
|
|
|
|
|
declare c1 cursor for select * from int8_tbl limit 10;
|
|
|
|
fetch all in c1;
|
|
|
|
fetch 1 in c1;
|
|
|
|
fetch backward 1 in c1;
|
|
|
|
fetch backward all in c1;
|
|
|
|
fetch backward 1 in c1;
|
|
|
|
fetch all in c1;
|
|
|
|
|
|
|
|
declare c2 cursor for select * from int8_tbl limit 3;
|
|
|
|
fetch all in c2;
|
|
|
|
fetch 1 in c2;
|
|
|
|
fetch backward 1 in c2;
|
|
|
|
fetch backward all in c2;
|
|
|
|
fetch backward 1 in c2;
|
|
|
|
fetch all in c2;
|
|
|
|
|
|
|
|
declare c3 cursor for select * from int8_tbl offset 3;
|
|
|
|
fetch all in c3;
|
|
|
|
fetch 1 in c3;
|
|
|
|
fetch backward 1 in c3;
|
|
|
|
fetch backward all in c3;
|
|
|
|
fetch backward 1 in c3;
|
|
|
|
fetch all in c3;
|
|
|
|
|
|
|
|
declare c4 cursor for select * from int8_tbl offset 10;
|
|
|
|
fetch all in c4;
|
|
|
|
fetch 1 in c4;
|
|
|
|
fetch backward 1 in c4;
|
|
|
|
fetch backward all in c4;
|
|
|
|
fetch backward 1 in c4;
|
|
|
|
fetch all in c4;
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
|
2007-05-17 21:35:08 +02:00
|
|
|
-- Stress test for variable LIMIT in conjunction with bounded-heap sorting
|
|
|
|
|
|
|
|
SELECT
|
|
|
|
(SELECT n
|
|
|
|
FROM (VALUES (1)) AS x,
|
|
|
|
(SELECT n FROM generate_series(1,10) AS n
|
|
|
|
ORDER BY n LIMIT 1 OFFSET s-1) AS y) AS z
|
|
|
|
FROM generate_series(1,10) AS s;
|
When appropriate, postpone SELECT output expressions till after ORDER BY.
It is frequently useful for volatile, set-returning, or expensive functions
in a SELECT's targetlist to be postponed till after ORDER BY and LIMIT are
done. Otherwise, the functions might be executed for every row of the
table despite the presence of LIMIT, and/or be executed in an unexpected
order. For example, in
SELECT x, nextval('seq') FROM tab ORDER BY x LIMIT 10;
it's probably desirable that the nextval() values are ordered the same
as x, and that nextval() is not run more than 10 times.
In the past, Postgres was inconsistent in this area: you would get the
desirable behavior if the ordering were performed via an indexscan, but
not if it had to be done by an explicit sort step. Getting the desired
behavior reliably required contortions like
SELECT x, nextval('seq')
FROM (SELECT x FROM tab ORDER BY x) ss LIMIT 10;
This patch conditionally postpones evaluation of pure-output target
expressions (that is, those that are not used as DISTINCT, ORDER BY, or
GROUP BY columns) so that they effectively occur after sorting, even if an
explicit sort step is necessary. Volatile expressions and set-returning
expressions are always postponed, so as to provide consistent semantics.
Expensive expressions (costing more than 10 times typical operator cost,
which by default would include any user-defined function) are postponed
if there is a LIMIT or if there are expressions that must be postponed.
We could be more aggressive and postpone any nontrivial expression, but
there are costs associated with doing so: it requires an extra Result plan
node which adds some overhead, and postponement changes the volume of data
going through the sort step, perhaps for the worse. Since we tend not to
have very good estimates of the output width of nontrivial expressions,
it's hard to have much confidence in our ability to predict whether
postponement would increase or decrease the cost of the sort; therefore
this patch doesn't attempt to make decisions conditionally on that.
Between these factors and a general desire not to change query behavior
when there's not a demonstrable benefit, it seems best to be conservative
about applying postponement. We might tweak the decision rules in the
future, though.
Konstantin Knizhnik, heavily rewritten by me
2016-03-11 18:27:41 +01:00
|
|
|
|
|
|
|
--
|
|
|
|
-- Test behavior of volatile and set-returning functions in conjunction
|
|
|
|
-- with ORDER BY and LIMIT.
|
|
|
|
--
|
|
|
|
|
|
|
|
create temp sequence testseq;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select unique1, unique2, nextval('testseq')
|
|
|
|
from tenk1 order by unique2 limit 10;
|
|
|
|
|
|
|
|
select unique1, unique2, nextval('testseq')
|
|
|
|
from tenk1 order by unique2 limit 10;
|
|
|
|
|
|
|
|
select currval('testseq');
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select unique1, unique2, nextval('testseq')
|
|
|
|
from tenk1 order by tenthous limit 10;
|
|
|
|
|
|
|
|
select unique1, unique2, nextval('testseq')
|
|
|
|
from tenk1 order by tenthous limit 10;
|
|
|
|
|
|
|
|
select currval('testseq');
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select unique1, unique2, generate_series(1,10)
|
|
|
|
from tenk1 order by unique2 limit 7;
|
|
|
|
|
|
|
|
select unique1, unique2, generate_series(1,10)
|
|
|
|
from tenk1 order by unique2 limit 7;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select unique1, unique2, generate_series(1,10)
|
|
|
|
from tenk1 order by tenthous limit 7;
|
|
|
|
|
|
|
|
select unique1, unique2, generate_series(1,10)
|
|
|
|
from tenk1 order by tenthous limit 7;
|
2016-03-25 16:19:51 +01:00
|
|
|
|
|
|
|
-- use of random() is to keep planner from folding the expressions together
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select generate_series(0,2) as s1, generate_series((random()*.1)::int,2) as s2;
|
|
|
|
|
|
|
|
select generate_series(0,2) as s1, generate_series((random()*.1)::int,2) as s2;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select generate_series(0,2) as s1, generate_series((random()*.1)::int,2) as s2
|
|
|
|
order by s2 desc;
|
|
|
|
|
|
|
|
select generate_series(0,2) as s1, generate_series((random()*.1)::int,2) as s2
|
|
|
|
order by s2 desc;
|
2016-07-02 19:23:02 +02:00
|
|
|
|
|
|
|
-- test for failure to set all aggregates' aggtranstype
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(tenthous) as s1, sum(tenthous) + random()*0 as s2
|
|
|
|
from tenk1 group by thousand order by thousand limit 3;
|
|
|
|
|
|
|
|
select sum(tenthous) as s1, sum(tenthous) + random()*0 as s2
|
|
|
|
from tenk1 group by thousand order by thousand limit 3;
|