"Gregory Stark" <[EMAIL PROTECTED]> writes: > "Andreas Joseph Krogh" <[EMAIL PROTECTED]> writes: > >> That's what I'm doing now. I run the query with "limit+1" as limit and if it >> results in more than limit, I know there is more data and I run count(*) to >> count them all. But count(*) cannot use indices in PG so it's limited in >> speed anyway AFAICS. > > Well count(*) can use indexes the same as the query can. > >> I really hoped there was an "Oracle over()" equivalent way in PG. I >> understand >> that Oracle's LIMIT-hack with "3 subselects and rownum between 1 AND 20" is >> rather expensive compared to PG's implementation of LIMIT. Oralce keeps >> snapshot-info in the index, so counting only involves the index AFAIK. > > Well that's only going to be true if the index satisfies the whole query which > is not going to be true for the simplest cases.
er, *except* for the simplest cases. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
