Re: Shouldn't the planner have a higher cost for reverse index scans?

Tom,

Right, because they do.  If you think otherwise, demonstrate it.
(bonnie tests approximating a reverse seqscan are not relevant
to the performance of indexscans.)

Working on it.  I *think* I've seen this issue in the field, which is why I brought it up in the first place, but getting a good test case is, of course, difficult.

select comment_date
    from user_comments
    where user_comments.uid=1
    order by comment_date desc limit 1

Explain:
"Limit  (cost=0.00..2699.07 rows=1 width=8) (actual time=52848.785..52848.787 rows=1 loops=1)"
"  ->  Index Scan Backward using idx_user_comments_comment_date on user_comments  (cost=0.00..5789515.40 rows=2145 width=8) (actual time=52848.781..52848.781 rows=1 loops=1)"
"        Filter: (uid = 1)"
"Total runtime: 52848.840 ms"

select comment_date
    from user_comments
    where user_comments.uid=1
    order by comment_date limit 1

Explain:
"Limit  (cost=0.00..2699.07 rows=1 width=8) (actual time=70.402..70.403 rows=1 loops=1)"
"  ->  Index Scan using idx_user_comments_comment_date on user_comments  (cost=0.00..5789515.40 rows=2145 width=8) (actual time=70.398..70.398 rows=1 loops=1)"
"        Filter: (uid = 1)"
"Total runtime: 70.453 ms"

CREATE INDEX idx_user_comments_comment_date
  ON user_comments
  USING btree
  (comment_date);