Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 37CBF47591A for ; Mon, 3 Jun 2002 19:38:47 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 8FDE7475909 for ; Mon, 3 Jun 2002 19:38:46 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g53NcVb12993; Mon, 3 Jun 2002 19:38:37 -0400 (EDT) To: russm Cc: pgsql-sql@postgresql.org Subject: Re: alternate idioms for large "IN (...)" lists In-reply-to: References: Comments: In-reply-to russm message dated "Mon, 03 Jun 2002 16:45:36 +1000" Date: Mon, 03 Jun 2002 19:38:31 -0400 Message-ID: <12990.1023147511@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200206/17 X-Sequence-Number: 7982 russm writes: > Just out of curiosity, why does postgresql's IN perform so poorly? Because no one's gotten around to improving it. The current implementation is actually just fine for small numbers of values in the IN-list. Making it work nicely for large numbers of values without pessimizing the small-list case would involve supporting (at least) two implementations and teaching the planner how to choose one. This definitely should be done, but has not gotten to the top of anyone's to-do queue. Most of the complaints we've seen about IN performance have to do with the IN-subselect case, which is yet a different animal. It's likely that that will get fixed before anyone worries about the large-number- of-scalar-values case... regards, tom lane