Dan Harris <fbsd@xxxxxxxxxxxxxxx> writes: > I have a query that is intended to select from multiple "small tables" > to get a limited subset of "incidentid" and then join with a "very > large" table. One of the operations will require a sequential scan, but > the planner is doing the scan on the very large table before joining the > small ones, resulting in a huge amount of disk I/O. How would I make > this query join the large table only after narrowing down the possible > selections from the smaller tables? This is running on version 8.0.3. That's very strange --- the estimated cost of the seqscan is high enough that the planner should have chosen a nestloop with inner indexscan on the big table. I'm not sure about the join-order point, but the hash plan for the first join seems wrong in any case. Um, you do have an index on eventactivity.incidentid, right? What's the datatype(s) of the incidentid columns? What happens to the plan if you turn off enable_hashjoin and enable_mergejoin? regards, tom lane
