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

Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
Date: 2009-03-30 14:16:11
Message-ID: 3028.1238422571@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr> writes:
>     ->  Bitmap Heap Scan on photo_info_data u  (cost=39134.84..63740.08 
> rows=109024 width=50) (actual time=270.464..270.469 rows=3 loops=2)
>           Recheck Cond: ((u.field_name)::text = (t.key)::text)
>           ->  Bitmap Index Scan on photo_info_data_pk 
> (cost=0.00..39107.59 rows=109024 width=0) (actual time=270.435..270.435 
> rows=3 loops=2)
>                 Index Cond: ((u.field_name)::text = (t.key)::text)

You need to figure out why that rowcount estimate is off by more than
four orders of magnitude :-(

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Mario SplivaloDate: 2009-03-30 15:34:31
Subject: Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
Previous:From: Mario SplivaloDate: 2009-03-30 14:07:51
Subject: Forcing seq_scan off for large table joined with tiny table yeilds improved performance

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