postgresql limit offset

hege

　　LIMIT 和 OFFSET
　　附加上 LIMIT和OFFSET 子句之后，你就可以检索原来查询语句查询出来的结果中的一部分数据行：

SELECT select_list
FROM table_expression
[LIMIT { number | ALL }] [OFFSET number]

　　如果给出了一个限制计数，那么返回不超过那么多的行。（但可能更少些，因为查询本身可能生成的行数就比较少。） LIMIT ALL 和省略 LIMIT 子句一样。
　　OFFSET 说明在开始返回行之前忽略多少行。 OFFSET 0 和省略 OFFSET 子句是一样的。如果 OFFSET 和 LIMIT 都出现了，那么在计算 LIMIT 个行之前忽略 OFFSET 行。
　　如果使用LIMIT，那么用ORDER BY 子句把结果行约束成一个唯一的顺序是一个好主意。否则你就会拿到一个不可预料的该查询的行的子集。--- 你要的可能是第十到二十行，但以什么顺序的十到二十？除非你声明了 ORDER BY，否则顺序是不知道的。
　　查询优化器在生成查询规划的时候会考虑LIMIT，因此如果你给 LIMIT和OFFSET不同的东西，那么你很可能收到不同的规划（产生不同的行顺序）。 因此，使用不同的LIMIT/OFFSET值选择不同的查询结果的子集将生成不一致的结果， 除非你用ORDER BY强制一个可预料的顺序。这可不是臭虫； 这是一个很自然的结果，因为 SQL 没有许诺把查询的结果按照任何特定的顺序发出，除非用了ORDER BY来约束顺序。
　　OFFSET 子句忽略的行仍然需要在服务器内部计算；因此，一个很大的 OFFSET 可能还是不够有效率的。
　　<!-- Saved in parser cache with key pgwiki:pcache:idhash:78-0!1!0!!zh-cn!2 and timestamp 20091111072556 -->

取自"http://www.pgsqldb.org/mwiki/index.php/LIMIT_%E5%92%8C_OFFSET"

关于limit，offset后能不能加表达式及子查询的问题，有人说可以，有人说不可以

http://topic.csdn.net/u/20091030/10/398e95cd-4d24-4b7a-9403-ebf8965e900b.html

得出不同结论的原因，怀疑是postgresql8.4的新特性

于是稍微搜了下

http://www.postgresql.org/docs/8.4/static/release-8-4.html

看了看postgresql8.4的release log，果然如此，并且有两条说明

一个是

写道

Disallow negative LIMIT or OFFSET values, rather than treating them as zero (Simon)




 

一个是

写道

E.2.3.3.3. LIMIT/OFFSET

Allow sub-selects in LIMIT and OFFSET (Tom)

Add SQL-standard syntax for LIMIT/OFFSET capabilities (Peter)

To wit, OFFSET num {ROW|ROWS} FETCH {FIRST|NEXT} [num] {ROW|ROWS} ONLY.




 

怪不得那些个大牛闲的没事就看这种log

可怜我是前台的体力劳动者了。。。。。。哪有闲工夫来研究这个

ps 为什么我必须跑了前面跑后面呢？前台的这些玩意儿更新的够快，整天层出不穷的库啊，架啊，后面也更新的这么快，还要不要活了？
　　<!-- end content -->