Re: Need help with one query

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

In response to

Browse pgsql-performance by date

  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