From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Anne Rosset <arosset(at)collab(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Need help with one query |
Date: | 2009-03-20 15:27:57 |
Message-ID: | 13823.1237562877@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Richard Huxton <dev(at)archonet(dot)com> writes:
>> Hash Join (cost=8.79..253664.55 rows=4 width=136) (actual
>> time=4612.674..6683.158 rows=4 loops=1)
>> Hash Cond: ((audit_change.audit_entry_id)::text = (audit_entry.id)::text)
>> -> Seq Scan on audit_change (cost=0.00..225212.52 rows=7584852
>> width=123) (actual time=0.009..2838.216 rows=7584852 loops=1)
>> -> Hash (cost=8.75..8.75 rows=3 width=45) (actual time=0.049..0.049
>> rows=4 loops=1)
>> -> Index Scan using audit_entry_object on audit_entry
>> (cost=0.00..8.75 rows=3 width=45) (actual time=0.033..0.042 rows=4 loops=1)
>> Index Cond: ((object_id)::text = 'artf414029'::text)
>> Total runtime: 6683.220 ms
> Very odd. It knows the table is large and that the seq-scan is going to
> be expensive.
Yeah, *very* odd. A nestloop with inner indexscan should have an
estimated cost far lower than this plan. What Postgres version is
this exactly? Do you have any nondefault planner parameter settings?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Wakeling | 2009-03-20 15:28:44 | Re: Proposal of tunable fix for scalability of 8.4 |
Previous Message | Glyn Astill | 2009-03-20 12:02:01 | Re: Prepared statement does not exist |