Re: Trimming the cost of ORDER BY in a simple query

On Mon, 2005-05-02 at 21:35 -0700, ogjunk-pgjedan(at)YAHOO(dot)COM wrote:

> Query (shows the last 7 dates):
>
> => SELECT DISTINCT date_part('year', uu.add_date), date_part('month',
> uu.add_date), date_part('day', uu.add_date) FROM user_url uu WHERE
> uu.user_id=1 ORDER BY date_part('year', uu.add_date) DESC,
> date_part('month', uu.add_date) DESC, date_part('day', uu.add_date)
> DESC LIMIT 7;
>

i assume add_date is a timestamp, because otherwise you could
ORDER by add_date, and use an index on (desc, add_date):
SELECT DISTINCT .... WHERE uu.user_id=1
ORDER BY uu.user_id DESC ,uu.add_date DESC LIMIT 7;

this will not work for a timestamp add_date

> QUERY PLAN:
...
> Total runtime: 20.313 ms

20 ms does not sound like a big problem.

if 20 ms is really too much for you, and add_date IS a timestamp,
you might think about adding a date column , maintained
by triggers of by your application, and add an index on (user_id, x)

another possibility (total guess) is a functional index
create index func_id_date on user_url(user_id,(add_date::date));
SELECT ... ORDER BY uu.user_id DESC ,uu.add_date::date DESC LIMIT 7;
I have no idea if this will work, or if the planner will use such
an index.

gnari