oracle rownum与greenplum分析性函数row_number的异同点

先知

熟悉oracle rownum伪列的人，都知道下面两个注意事项：
（1）不能对rownum使用>（大于1的数值）、>=（大于1的数值）、=（大于1的数值），否则无结果。
（2）在使用rownum时，只有当Order By的字段是主键时，查询结果才会先排序再计算rownum，但是，对非主键字段（如：name）进行排序时，结果可能就混乱了。出现混乱的原因是：oracle先按物理存储位置（rowid）顺序取出满足rownum条件的记录，即物理位置上的前5条数据，然后在对这些数据按照Order By的字段进行排序，而不是我们所期望的先排序、再取特定记录数。

实验

下面我们使用一些例子来探究一下oracle rownum在实际使用过程中的情况；
前提条件：
create table frownum(id int);
insert into frownum values(1);
insert into frownum values(2);
insert into frownum values(3);
insert into frownum values(4);
insert into frownum values(5);
insert into frownum values(6);
insert into frownum values(7);
(1)先查询一下：
再使用update进行更新：

发现：更新之后，行号并没有发生改变。
(2)先看postgres:

发现更新的列在最后一排，因此update更新操作结果与Oracle rownum 不一致
(3)再来看看greenplum：

再使用update进行更新：

可以看见更新之后，7和8位置进行了交换。
我们现在加上 row_number() over () as rownum函数再来看看它的特性是否与oracle的rownum相同。
drop掉frownum表之后重新创建。查询结果如下：

我们连续查询了三次，其结果输出每次的顺序都不一致。
使用order by固定id:
说明row_number() over() 分析函数不能与oracle rownum兼容。也就没有必要继续往下测试了。原因是
greepplum在查询时使用了优化
可与postgres执行计划做对比：