X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 891BAD1B907 for ; Wed, 20 Aug 2003 17:32:33 -0300 (ADT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 89440-09 for ; Wed, 20 Aug 2003 17:32:23 -0300 (ADT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by svr1.postgresql.org (Postfix) with ESMTP id 5EC29D1BAA8 for ; Wed, 20 Aug 2003 17:32:21 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.9/8.12.9) with ESMTP id h7KKWJ5H018609; Wed, 20 Aug 2003 16:32:19 -0400 (EDT) To: Mike Winter Cc: pgsql-sql@postgresql.org Subject: Re: "SELECT IN" Still Broken in 7.4b In-reply-to: References: Comments: In-reply-to Mike Winter message dated "Wed, 20 Aug 2003 12:51:13 -0600" Date: Wed, 20 Aug 2003 16:32:19 -0400 Message-ID: <18608.1061411539@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/242 X-Sequence-Number: 14858 Mike Winter writes: > MySQL does queries of this type orders of magnitudes faster than Postgres > on large value lists, although I have no specific algorithmic solutions to > offer for how to make it faster. How large is "large", and what plan type are you getting (seq scan or multiple index scan)? Is it possible that the cost comes from planner overhead and not execution? Checking EXPLAIN ANALYZE reported time against actual elapsed time (cf psql's \timing option) would tell. regards, tom lane