From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | cmusielak(at)akio-software(dot)com |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 7.4 performance issue |
Date: | 2004-06-16 13:48:42 |
Message-ID: | 21459.1087393722@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Christophe Musielak <cmusielak(at)akio-software(dot)com> writes:
> -> Seq Scan on threads t
> (cost=0.00..19431.23
> rows=82667 width=583)
> Filter: (((mailbox_id = 2) OR
> (mailbox_id
> = 3) OR (mailbox_id = 5) OR (mailbox_id = 20) OR (mailbox_id = 21) OR
> (mailbox_id = 13) OR (mailbox_id = 22) OR (mailbox_id =
> 23)
> OR (mailbox_id = 24) OR (mailbox_id = 25) OR (mailbox_id = 26)
> OR (mailbox_id = 19)) AND (desktop = 2))
Although it's hard to be sure without EXPLAIN ANALYZE output, it seems
like an index on threads(mailbox_id) might help here. You have a bunch
of other indexes on threads that are useless for this query :-( ...
I hope they are some good for other queries, else they're just slowing
down updates.
Also a larger value of sort_mem might help. At least by the planner's
estimates, the other big hit is the use of a merge join between emails
and threads. I think a hash join would work better, but it's not going
to pick that unless the inner relation will fit in sort_mem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff | 2004-06-16 14:01:32 | Visual Explain |
Previous Message | David Parker | 2004-06-16 13:40:49 | Re: building 7.4.3 on Solaris 9/Intel |