John Beaver <[EMAIL PROTECTED]> writes: > Can anyone explain this? There should only ever be a maximum of about 50 > rows returned when the query is executed.
Is the estimate that 197899 rows of gene_prediction_view have go_term_ref = 2 about right? If not, then we need to talk about fixing your statistics. If it is in the right ballpark then I do not see *any* plan for this query that runs in small time. The only way to avoid a seqscan on functional_linkage_scores would be to do 198K^2 index probes into it, one for each combination of matching fs1 and fs2 rows; I can guarantee you that that's not a win. The fact that the planner is estimating 352770803726 result rows compared to your estimate of 50 offers some hope that it's a stats problem, but ... regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance