Richard Huxton <dev@xxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
