As I understand it, Postgres's query planner considers only trees of
joins - I don't know what the technical implications are of using DAG
plans, other than the obvious blowup in planning space.
I was recently in a similar situation, where a script essentially
needed to do a self-join on the result of a complex query. The script
uses a temp table to store the results of the first query, and then
does a second query using the temp table - effectively, I have done
common-subexpression reduction by hand. This repeated fragment of your
example:
SELECT * FROM common_pmids('mycn','trka')
might be a candidate for such treatment.
- John Burger
MITRE