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

From: Tom Lane
Subject: Re: Shouldn't the planner have a higher cost for reverse index scans?
Date: ,
Msg-id: 18553.1239896194@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Shouldn't the planner have a higher cost for reverse index scans?  (Merlin Moncure)
List: pgsql-performance

Tree view

Shouldn't the planner have a higher cost for reverse index scans?  (Josh Berkus, )
 Re: Shouldn't the planner have a higher cost for reverse index scans?  (Tom Lane, )
  Re: Shouldn't the planner have a higher cost for reverse index scans?  (Josh Berkus, )
   Re: Shouldn't the planner have a higher cost for reverse index scans?  (Tom Lane, )
    Re: Shouldn't the planner have a higher cost for reverse index scans?  (Josh Berkus, )
     Re: Shouldn't the planner have a higher cost for reverse index scans?  (Lists, )
      Re: Shouldn't the planner have a higher cost for reverse index scans?  (Grzegorz Jaśkiewicz, )
      Re: Shouldn't the planner have a higher cost for reverse index scans?  (Merlin Moncure, )
       Re: Shouldn't the planner have a higher cost for reverse index scans?  (Tom Lane, )
      Re: Shouldn't the planner have a higher cost for reverse index scans?  (Tom Lane, )
       Re: Shouldn't the planner have a higher cost for reverse index scans?  (Lists, )
        Re: Shouldn't the planner have a higher cost for reverse index scans?  (Tom Lane, )
    Re: Shouldn't the planner have a higher cost for reverse index scans?  (Matthew Wakeling, )

Merlin Moncure <> writes:
> On Thu, Apr 16, 2009 at 2:02 AM, Lists <> wrote:
>> select comment_date
>>     from user_comments
>>     where user_comments.uid=1
>>     order by comment_date desc limit 1

> try this:
> create index comment_data_uid_idx on user_comments(uid, comment_date);

> select * from user_comments where (uid, comment_date) < (1, high_date)
>   order by uid desc, comment_date desc limit 1;

You don't really need to complicate your queries like that.  Having the
two-column index will suffice to make the given query work fine, at
least in reasonably modern PG versions (since 8.1 I think).

            regards, tom lane


pgsql-performance by date:

From: Matthew Wakeling
Date:
Subject: Re: GiST index performance
From: Kris Jurka
Date:
Subject: No hash join across partitioned tables?