As for optimizing the query, I noticed that all three joins are done by
nested loops. I wonder if another join method would be faster. Have you
analyzed all the tables?
Yes. I did a VACUUM FULL ANALYZE before running the test queries. Also I
have just performed an ANALYZE just to be sure everything was really
analyzed.
You aren't disabling hash joins or merge joins are
you?
Nope.
If you aren't, then as a test I would try disabling nested loops by
doing "set enable_nestloop=false" and see if the query is any faster for
you.
If I disable the nested loops, the query becomes *much* slower.
A thing that strikes me is the following. As you can see I have the
constraint: q.status = 1. Only a small subset of the data set has this
status. I have an index on q.status but for some reason this is not
used. Instead the constraint are ensured with a "Filter: (q.status = 1)"
in an index scan for the primary key in the "q" table. If the small
subset having q.status = 1 could be isolated quickly using an index, I
would expect the query to perform better. I just don't know why the
planner doesn't use the index on q.status.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
