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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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