From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | dbichko(at)genpathpharma(dot)com (Dmitri Bichko) |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: OFFSET and subselects |
Date: | 2003-11-29 06:38:22 |
Message-ID: | 87ad6ffzmp.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
dbichko(at)genpathpharma(dot)com (Dmitri Bichko) writes:
> I am running in trouble with pagination here, somehow (rather naively) I
> assumed that when doing a LIMIT and OFFSET, the subselects on the records
> before the OFFSET would not be performed, which quite apparently is not the
> case. So, LIMIT 50 OFFSET 0 takes 100ms to run, LIMIT 50 OFFSET 50 takes
> 200ms, LIMIT 50 OFFSET 100 takes 300ms; and so forth, this really becomes
> unacceptable after a few pages.
If you don't need any of the results of the subqueries in your WHERE clause
then you can do this by introducing a view in your query like:
SELECT *,
(SELECT ...) AS sub_1,
(SELECT ...) AS sub_2,
(SELECT ...) AS sub_3
FROM (
SELECT x,y,z
FROM ...
WHERE ...
)
LIMIT 50
OFFSET 50
If you do use the results of the subqueries in your where clause or order by
clause then, well, you're SOL. Since the OFFSET and LIMIT clauses only kick in
after the where clause restrictions are taken into account.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | ow | 2003-11-29 16:49:24 | Seq Scans when index expected to be used |
Previous Message | George A.J | 2003-11-29 03:20:21 | Infinite loop crashes server |