On Wed, Jan 11, 2006 at 10:30:58PM +0100, Bendik Rognlien Johansen wrote:
> The sort is definitively the culprit. When I removed it the query was
> instant. I tried setting work_mem = 131072 but it did not seem to
> help. I really don't understand this :-( Any other ideas?
What's explain analy
The sort is definitively the culprit. When I removed it the query was
instant. I tried setting work_mem = 131072 but it did not seem to
help. I really don't understand this :-( Any other ideas?
Thanks!
On Jan 11, 2006, at 9:23 PM, Jim C. Nasby wrote:
I'd try figuring out if the join is th
I'd try figuring out if the join is the culprit or the sort is (by
dropping the ORDER BY). work_mem is probably forcing the sort to spill
to disk, and if your drives are rather busy...
You might also get a win if you re-order the joins to people, contacts,
addresses, if you know it will have the s
Yes, the rowcount estimates are real, however, it has been a long
time since the last VACUUM FULL (there is never a good time).
I have clustered the tables, reindexed, analyzed, vacuumed and the
plan now looks like this:
no_people=# explain SELECT r.id AS r_id, r.firstname || ' ' ||
r.l
Bendik Rognlien Johansen <[EMAIL PROTECTED]> writes:
> Has anyone got any tips for speeding up this query? It currently
> takes hours to start.
Are the rowcount estimates close to reality? The plan doesn't look
unreasonable to me if they are. It might help to increase work_mem
to ensure that t
Hello!
Has anyone got any tips for speeding up this query? It currently
takes hours to start.
PostgreSQL v8.x on (SuSe Linux)
Thanks!
no_people=# explain SELECT r.id AS r_id, r.firstname || ' ' ||
r.lastname AS r_name, ad.id AS ad_id, ad.type AS ad_type, ad.address
AS ad_address, ad.post
