Re: sub select performance due to seq scans - Mailing list pgsql-performance

From Tom Lane
Subject Re: sub select performance due to seq scans
Date
Msg-id 14463.1154356126@sss.pgh.pa.us
Whole thread Raw
In response to Re: sub select performance due to seq scans  (H Hale <hhale21@rogers.com>)
Responses Re: sub select performance due to seq scans  (H Hale <hhale21@rogers.com>)
List pgsql-performance
H Hale <hhale21@rogers.com> writes:
>     ->  Bitmap Heap Scan on flatomfilesysentry  (cost=2.00..274.38 rows=3238 width=30) (actual time=0.011..0.013
rows=1loops=6473) 
>           Recheck Cond: (flatomfilesysentry.objectid = "outer".dstobj)
>           ->  Bitmap Index Scan on flatomfilesysentry_pkey  (cost=0.00..2.00 rows=3238 width=0) (actual
time=0.007..0.007rows=1 loops=6473) 
>                 Index Cond: (flatomfilesysentry.objectid = "outer".dstobj)

Well, there's our estimation failure: 3238 rows expected, one row
actual.

What is the data distribution of flatomfilesysentry.objectid?
It looks from this example like it is unique or nearly so,
but the planner evidently does not think that.

            regards, tom lane

pgsql-performance by date:

Previous
From: H Hale
Date:
Subject: Re: sub select performance due to seq scans
Next
From: Axel Rau
Date:
Subject: Re: directory tree query with big planner variation