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

2009-04-06 Thread Scott Marlowe
On Mon, Apr 6, 2009 at 8:50 AM, Mario Splivalo wrote: > Scott Marlowe wrote: >>> >>> CREATE INDEX photo_info_data_ix_field_value >>>  ON user_info_data USING btree (field_value); >>> >>> So, there is index on (user_id, field_name). Postgres is using index for >>> user_id (...WHERE user_id = 12345)

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

2009-04-06 Thread Mario Splivalo
Scott Marlowe wrote: CREATE INDEX photo_info_data_ix_field_value ON user_info_data USING btree (field_value); So, there is index on (user_id, field_name). Postgres is using index for user_id (...WHERE user_id = 12345) but not on field-name (...WHERE field_name = 'f-spot'). When I add extra inde

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

2009-04-06 Thread Scott Marlowe
On Mon, Apr 6, 2009 at 8:37 AM, Mario Splivalo wrote: > Scott Marlowe wrote: >> >> On Mon, Apr 6, 2009 at 6:20 AM, Mario Splivalo >> wrote: >>> >>> Scott Marlowe wrote: It's not really solved, it's just a happy coincidence that the current plan runs well.  In order to keep the quer

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

2009-04-06 Thread Mario Splivalo
Scott Marlowe wrote: On Mon, Apr 6, 2009 at 6:20 AM, Mario Splivalo wrote: Scott Marlowe wrote: It's not really solved, it's just a happy coincidence that the current plan runs well. In order to keep the query planner making good choices you need to increase stats target for the field in the

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

2009-04-06 Thread Scott Marlowe
On Mon, Apr 6, 2009 at 6:20 AM, Mario Splivalo wrote: > Scott Marlowe wrote: >> >> It's not really solved, it's just a happy coincidence that the current >> plan runs well.  In order to keep the query planner making good >> choices you need to increase stats target for the field in the index >> ab

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

2009-04-06 Thread Mario Splivalo
Scott Marlowe wrote: It's not really solved, it's just a happy coincidence that the current plan runs well. In order to keep the query planner making good choices you need to increase stats target for the field in the index above. The easiest way to do so is to do this: alter database mydb se

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

2009-03-30 Thread Scott Marlowe
On Mon, Mar 30, 2009 at 9:34 AM, Mario Splivalo wrote: >         ->  Bitmap Heap Scan on photo_info_data u (cost=2193.50..26798.74 > rows=109024 width=9) (actual time=0.025..0.030 rows=3 loops=2) >               Recheck Cond: ((u.field_name)::text = (t.key)::text) >               ->  Bitmap Index

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

2009-03-30 Thread Mario Splivalo
Tom Lane wrote: 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_p

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

2009-03-30 Thread Tom Lane
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=

[PERFORM] Forcing seq_scan off for large table joined with tiny table yeilds improved performance

2009-03-30 Thread Mario Splivalo
I have two tables, like this: Big table: CREATE TABLE photo_info_data ( photo_id integer NOT NULL, field_name character varying NOT NULL, field_value character varying, CONSTRAINT photo_info_data_pk PRIMARY KEY (photo_id, field_name) ) WITH (OIDS=FALSE); CREATE INDEX user_info_data_ix_f