Ragnar Hafstað wrote:
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.
To make sur
In article <[EMAIL PROTECTED]>,
Ragnar Hafstað <[EMAIL PROTECTED]> writes:
> 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 inde
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_da
Quoting [EMAIL PROTECTED]:
> I have a simple query with a pretty high cost (EXPLAIN ...), and I'm
> wondering if I can somehow trim it.
>
> Query (shows the last 7 dates):
>
> => SELECT DISTINCT date_part('year', uu.add_date),
> date_part('month',
> uu.add_date), date_part('day', u
Hello,
I have a simple query with a pretty high cost (EXPLAIN ...), and I'm
wondering if I can somehow trim it.
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_
