Skip site navigation (1) Skip section navigation (2)

Re: sub select performance due to seq scans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: H Hale <hhale21(at)rogers(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: sub select performance due to seq scans
Date: 2006-07-31 14:28:46
Message-ID: 14463.1154356126@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
H Hale <hhale21(at)rogers(dot)com> writes:
>     ->  Bitmap Heap Scan on flatomfilesysentry  (cost=2.00..274.38 rows=3238 width=30) (actual time=0.011..0.013 rows=1 loops=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.007 rows=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

In response to

Responses

pgsql-performance by date

Next:From: Axel RauDate: 2006-07-31 15:06:00
Subject: Re: directory tree query with big planner variation
Previous:From: H HaleDate: 2006-07-31 14:14:27
Subject: Re: sub select performance due to seq scans

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group