I don't know why they have it set so low by default ... among other things the genetic query optimizer hasn't been worked on in a long time and little is understood about it in the community.
This needs to get written up in our installation documents ... I think setting it high enough so that GEQO is turned off is the best things for us to do.
And now that PL/pgSQL procs can return rowsets in PG 7.3, one can remove the plan optimization overhead by burying something like this in a function (each back end generates a plan for a PL/pgSQL function once per back end lifetime)
In fact for future planning you might want to mark the query to that effect ... for the day when we dump PG 7.2 support.
There's some way to find out how long the planner takes vs. execution, though like many of the stats information functions available it doesn't seem to be documented in the 7.3 HTML docs I've looked through.
If the planner's taking (say) 60 ms of that 100 ms then burying it in a PL/pgSQL function will represent a real savings but it would be best, of course, to measure first and hack later.
I assume you mean you cut out most of the columns being returned, not the WHERE clause, which appears to be there in all its full glory. If all you need is the bug_id then we can suggest several simplifications to the query :)
