On Mon, 2005-05-02 at 21:35 -0700, [EMAIL PROTECTED] 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend