Chris Beecroft <[EMAIL PROTECTED]> writes:
> Our problem is that about a week and a half ago we started to get some
> queries that would (seemingly) never return (e.g., normally run in a
> couple minutes, but after 2.5 hours, they were still running, the
> process pushing the processor up to 99.9% active).
> Attached are an example query plan: Query.sql
> The query plan from our production sever: QueryPlanBroke.txt
> The working query plan from our backup server: QueryPlanWork.txt
Note the major difference in estimated row counts. That's the key to
your problem... you need to find out why the "broke" case thinks only
one row is getting selected.
broke:
> -> Nested Loop (cost=30150.77..129334.04 rows=1 width=305)
work:
> -> Hash Join (cost=30904.77..125395.89 rows=1810 width=306)
I'm wondering about out-of-date or nonexistent ANALYZE stats, missing
custom adjustments of statistics target settings, etc.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
