From: | Ragnar <gnari(at)hive(dot)is> |
---|---|
To: | Harry Hehl <Harry(dot)Hehl(at)diskstream(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Sequencial scan instead of using index |
Date: | 2006-03-06 20:51:46 |
Message-ID: | 1141678306.18656.152.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On mán, 2006-03-06 at 13:46 -0500, Harry Hehl wrote:
> Query: select * from ommemberrelation where srcobj='somevalue'
> and dstobj in (select objectid from omfilesysentry where name='dir15_file80');
>
> Columns srcobj, dstobj & name are all indexed.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Nested Loop IN Join (cost=486.19..101533.99 rows=33989 width=177) (actual time=5.493..90.682 rows=1 loops=1)
> Join Filter: ("outer".dstobj = "inner".objectid)
> -> Seq Scan on ommemberrelation (cost=0.00..2394.72 rows=33989 width=177) (actual time=0.078..70.887 rows=100 loops=1)
> Filter: (srcobj = '3197a4e6-abf1-11da-a0f9-000fb05ab829'::text)
> -> Materialize (cost=486.19..487.48 rows=129 width=16) (actual time=0.004..0.101 rows=26 loops=100)
Looks like the planner is expecting 33989 rows, making
an index scan a ppor choice, but in fact only 100 rows
actually match your srcobj value.
Could we see the explain analyze with enable_seqscan
= false please ?
Possibly you might want totry to increase the statistics
target for this columns , as in:
ALTER TABLE ommemberrelation ALTER COLUMN srcobj
SET STATISTICS 1000;
ANALYZE;
and try again (with enable_seqscan=true)
A target of 1000 ismost probably overkill, but
start with this value, and if it improves matters,
you can experiment with lower settings.
gnari
From | Date | Subject | |
---|---|---|---|
Next Message | Guido Neitzer | 2006-03-06 21:24:29 | Re: t1000/t2000 sun-servers |
Previous Message | Michael Fuhr | 2006-03-06 20:17:16 | Re: Can anyone explain this pgbench results? |