Just to let you know, the solution using SELECT * FROM (query with
offset/limit) works perfectly well. Thanks a lot for the suggestion!
I think the doc is right. I overcame the problem by using a construct like:
SELECT field1, field2? WHERE PKEY IN (SELECT PKEY ? WHERE OFFSET n LIMIT
m)
That executes a sub query.
But your solution looks actually better, as it is:
SELECT * FROM (SELECT field1, field2? WHERE OFFSET n LIMIT m)
Thanks. I know about the technique your mentioned, but the point is not about
the use of offset or not. The same issue will happen but using a key.
See my other reply above.
On Thu, 1 Oct 2015 13:40:23 +0200, Clemens Ladisch
wrote:
> OFFSET is inefficient because the database still has to compute all the
> rows before skipping over them.
>
> To do paging, remember the first and last date values on the page, and
> for the previous/next page, just continue from there:
Philippe Riand wrote:
> I have a table with 500,000+ records. The table has a date column,
> that I?m using to sort my queries (the columns has an index). Simple
> queries on the table work very well, using ORDER BY, LIMIT & OFFSET.
> I?m actually extracting ?pages? of rows that I?m displaying in
Op 1 okt 2015, om 04:10 heeft Philippe Riand wrote:
> I have a table with 500,000+ records. The table has a date column,
> that I?m using to sort my queries (the columns has an index). Simple
> queries on the table work very well, using ORDER BY, LIMIT & OFFSET.
> I?m actually extracting
I have a table with 500,000+ records. The table has a date column, that I?m
using to sort my queries (the columns has an index). Simple queries on the
table work very well, using ORDER BY, LIMIT & OFFSET. I?m actually extracting
?pages? of rows that I?m displaying in a web page. Great!.
Now,
7 matches
Mail list logo
