postgresql - Deducing estimated time taken with EXPLAIN -
the following explain output of query set enable_seqscan = true.
hash join (cost=1028288.04..278841855100.04 rows=429471108 width=125) hash cond: ((u.destination)::text = (n.mid)::text) -> nested loop (cost=0.00..278587474234.17 rows=429471108 width=112) join filter: (((u.destination)::text <> (u2.mid)::text) , ("position"((u2.path_name)::text, (suffix(u.path_name))::text) = 0) , (((prefix((u.path_name)::text))::text = (prefix((u2.path_name)::text))::text) or ((prefix((u.path_name)::text))::text = 'common'::text))) -> seq scan on unresolved u2 (cost=0.00..2780546.32 rows=117608632 width=79) -> index scan using unresolved__mid on unresolved u (cost=0.00..1864.44 rows=492 width=53) index cond: ((u.mid)::text = (u2.destination)::text) -> hash (cost=488335.24..488335.24 rows=27237024 width=33) -> seq scan on name n (cost=0.00..488335.24 rows=27237024 width=33)
(9 rows)
the following explain output of same query set enable_seqscan = false.
hash join (cost=102089128.45..279381508122.13 rows=429471108 width=125) hash cond: ((u.destination)::text = (n.mid)::text) -> nested loop (cost=0.00..279026066415.86 rows=429471108 width=112) join filter: (((u.destination)::text <> (u2.mid)::text) , ("position"((u2.path_name)::text, (suffix(u.path_name))::text) = 0) , (((prefix((u.path_name)::text))::text = (prefix((u2.path_name)::text))::text) or ((prefix((u.path_name)::text))::text = 'common'::text))) -> index scan using unresolved__destination on unresolved u2 (cost=0.00..441372728.01 rows=117608632 width=79) -> index scan using unresolved__mid on unresolved u (cost=0.00..1864.44 rows=492 width=53) index cond: ((u.mid)::text = (u2.destination)::text) -> hash (cost=101549175.65..101549175.65 rows=27237024 width=33) -> index scan using name_pkey on name n (cost=0.00..101549175.65 rows=27237024 width=33)
(9 rows)
i know how long query take. it's been running 10 hours now. estimated time deduced 'cost' in first row, in case of latter '279381508122.13 ms' 8.8 years?! :-(
the numbers not correspond time. relative numbers only. documentation (using explain):
the costs measured in arbitrary units determined planner's cost parameters (see section 18.6.2). traditional practice measure costs in units of disk page fetches; is, seq_page_cost conventionally set 1.0 , other cost parameters set relative that. (the examples in section run default cost parameters.)
in event, nested loop due vague join condition appears killing performance. hard tell without seeing original query , table/index structures, might find benefit in creating functional index on unresolved, assuming "prefix()" immutable function:
create index idx_path_name_prefix on unresolved (prefix(path_name));
Comments
Post a Comment