My mistake. Here's the other query that required parens in order to use the
index. But you'll see that it was parens in the WHERE clause, not in the
ORDER BY that helped in this example. So I tried adding parens to this ORDER
BY and, just like my original SELECT, the performance dropped off. So...
apparently it's important for me to use parens in the WHERE clase and avoid
parens in the ORDER BY.
SELECT * FROM test
WHERE (name, rowid) > ('j', 0) and (name, rowid) != ('', 0)
ORDER BY name, rowid
I populated this table with 1,000,000 rows.
CREATE TABLE test (
rowid serial PRIMARY KEY,
CREATE UNIQUE INDEX first_index ON test(name, rowid);
View this message in context: http://postgresql.1045698.n5.nabble.com/Just-trying-to-read-first-row-in-table-based-on-index-pg-scans-and-sorts-instead-tp5652859p5653210.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.
In response to
pgsql-novice by date
|Next:||From: Bartosz Dmytrak||Date: 2012-04-20 21:08:18|
|Subject: Re: Returning generated id after a transaction.|
|Previous:||From: Steve Crawford||Date: 2012-04-19 23:31:48|
|Subject: Re: Re: Just trying to read first row in table based on
index, pg scans and sorts instead?|