Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id B1662632E21 for ; Mon, 6 Apr 2009 11:38:05 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 77306-03 for ; Mon, 6 Apr 2009 11:37:54 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from megafon.hr (megafon.hr [213.202.104.5]) by mail.postgresql.org (Postfix) with ESMTP id E1850632D4B for ; Mon, 6 Apr 2009 11:38:03 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by megafon.hr (Postfix) with ESMTP id 224B22500A2; Mon, 6 Apr 2009 16:38:01 +0200 (CEST) X-Virus-Scanned: ClamAV at megafon.hr Received: from megafon.hr ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eYmeVwOAvM7; Mon, 6 Apr 2009 16:37:53 +0200 (CEST) Received: from [192.168.1.94] (unknown [212.92.194.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mike) by megafon.hr (Postfix) with ESMTP id 686252500A1; Mon, 6 Apr 2009 16:37:53 +0200 (CEST) Message-ID: <49DA13C1.2030200@megafon.hr> Date: Mon, 06 Apr 2009 16:37:53 +0200 From: Mario Splivalo User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Scott Marlowe CC: Tom Lane , pgsql-performance@postgresql.org Subject: Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance References: <49D0D237.7020308@megafon.hr> <3028.1238422571@sss.pgh.pa.us> <49D0E687.50605@megafon.hr> <49D9F39F.40106@megafon.hr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200904/130 X-Sequence-Number: 33497 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 index >>> above. The easiest way to do so is to do this: >>> >>> alter database mydb set default_statistics_target=100; >>> >>> and run analyze again: >>> >>> analyze; >> So, i removed the index on field_name, set default_default_statistics_target >> to 100, analyzed, and the results are the same: > > Why did you remove the index? > Because I already have index on that column, index needed to enforce PK constraint. Here is the original DDL for the 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 (user_id, field_name) ) 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 index on field name: CREATE INDEX photo_info_data_ix__field_name ON user_info_data USING btree (field_name); Then that index is used. Mike