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

From: Tom Lane
Subject: Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
Date: ,
Msg-id: 3028.1238422571@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo)
Responses: Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo)
List: pgsql-performance

Tree view

Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo, )
 Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Tom Lane, )
  Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo, )
   Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Scott Marlowe, )
    Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo, )
     Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Scott Marlowe, )
      Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo, )
       Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Scott Marlowe, )
        Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo, )
         Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Scott Marlowe, )

Mario Splivalo <> 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


pgsql-performance by date:

From: Robert Haas
Date:
Subject: Re: Trying to track down weird query stalls
From: dan@sidhe.org
Date:
Subject: Re: Trying to track down weird query stalls