Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 2A385475CC4 for ; Tue, 3 Dec 2002 02:06:17 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 7E45A4759BD for ; Tue, 3 Dec 2002 02:06:16 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.6/8.12.6) with ESMTP id gB376Gpd020935; Tue, 3 Dec 2002 02:06:16 -0500 (EST) To: Mike Winter Cc: pgsql-sql@postgresql.org Subject: Re: Question about slow Select when using 'IN'. In-reply-to: References: Comments: In-reply-to Mike Winter message dated "Fri, 29 Nov 2002 16:23:58 -0600" Date: Tue, 03 Dec 2002 02:06:16 -0500 Message-ID: <20934.1038899176@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200212/18 X-Sequence-Number: 10606 Mike Winter writes: > My query is of the form: > SELECT col, count(col) FROM tab WHERE id IN (3, > 4,7,2, ...) GROUP BY COL ORDER BY count > for a very large number of rows. > I have an index on id, so the explain looks like: > Aggregate (cost=12.12..12.14 rows=1 width=5) > -> Group (cost=12.12..12.13 rows=4 width=5) > -> Sort (cost=12.12..12.12 rows=4 width=5) > -> Index Scan using col_id_idx2, col_id_idx2, col_id_idx2, > col_id_idx2 on tab (cost=0.00..12.08 rows=4 width=5) The planner obviously does not think this is a large table (the cost estimates correspond to very small numbers of pages). I wonder whether you have ever VACUUMed or ANALYZEd the table. regards, tom lane