Some more thoughts...

Performance!!! (Imagine that, I'm pushing performance )

Now, I didn't have a timestamped column handy so I used the PK. I'm most interested in using a column that's indexed, as I assume the Inserted_TS would be. Here are some results on an ~11,000 record table:

SELECT /* test8 */
e1.org_pk, e1.legal_st_cd
FROM org e1
WHERE 2 > (
SELECT COUNT(*)
FROM org e2
WHERE e2.org_pk > e1.org_pk);

SELECT STATEMENT Optimizer=CHOOSE (Cost=33 Card=1137 Bytes=15918)
---FILTER
------TABLE ACCESS (FULL) OF ORG (Cost=33 Card=1137 Bytes=15918)
------SORT (AGGREGATE)
---------INDEX (RANGE SCAN) OF XPKORG (UNIQUE) (Cost=2 Card=1137 Bytes=4548)

LR: 312725
Time: 333 secs
----------------------------------------------------------------
SELECT /* test8 */
org_pk, legal_st_cd from
(select org_pk, legal_st_cd from org order by org_pk desc)
where rownum < 3

SELECT STATEMENT Optimizer=CHOOSE (Cost=73 Card=22734 Bytes=522882)
---COUNT (STOPKEY)
------VIEW (Cost=73 Card=22734 Bytes=522882)
---------SORT (ORDER BY STOPKEY) (Cost=73 Card=22734 Bytes=318276)
------------TABLE ACCESS (FULL) OF ORG (Cost=33 Card=22734 Bytes=318276)

LR: 845
Time : 0.69 secs
----------------------------------------------------------------
SELECT /* test8 */
* from
(select * from org order by org_pk desc)
where rownum < 3

SELECT STATEMENT Optimizer=CHOOSE (Cost=350 Card=22734 Bytes=87321294)
---COUNT (STOPKEY)
------VIEW (Cost=350 Card=22734 Bytes=87321294)
---------TABLE ACCESS (BY INDEX ROWID) OF ORG (Cost=350 Card=22734 Bytes=11162394)
------------INDEX (FULL SCAN DESCENDING) OF XPKORG (UNIQUE) (Cost=25 Card=22734)

LR: 4
Time: 0.05 secs
----------------------------------------------------------------
SELECT /* test8 */
org_pk, legal_st_cd from
(select distinct
-(org_pk - 100000) s,
org_pk, legal_st_cd---from org)
where rownum < 3;

SELECT STATEMENT Optimizer=CHOOSE (Cost=73 Card=22734 Bytes=522882)
---COUNT (STOPKEY)
------VIEW (Cost=73 Card=22734 Bytes=522882)
---------SORT (UNIQUE STOPKEY) (Cost=73 Card=22734 Bytes=318276)
------------TABLE ACCESS (FULL) OF ORG (Cost=33 Card=22734 Bytes=318276)

LR: 845
Time: 0.17
----------------------------------------------------------------

These were done, as always, multiple times on an isolated server.

What to note:
- If you can get the optimizer to do an INDEX SCAN DESCENDING, this is your best bet. Note how simply switching to * from a column list did this (wierd, huh?) . Of course, one would *never* use SELECT * in a production-query. Hinting it would be a better idea.
- DO NOT use the > COUNT sub-select proposed by akkerend. Sorry akkerend, but as the results show, that one was pretty bad . Not that it's your fault, I've seen this solution a lot of places too, including from Joe Celko. It just goes to show that nobody is perfect

Again, just trying to raise the awareness of how drastically one's choice of solutions can affect performance.

- Chris