X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 91E27D1B8E1 for ; Sun, 24 Aug 2003 18:37:34 -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 70056-02 for ; Sun, 24 Aug 2003 18:37:26 -0300 (ADT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by svr1.postgresql.org (Postfix) with ESMTP id 36BB4D1BB4B for ; Sun, 24 Aug 2003 18:37:16 -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 h7OLbE5H005914; Sun, 24 Aug 2003 17:37:15 -0400 (EDT) To: Stephan Szabo Cc: Dani Oderbolz , pgsql-hackers@postgresql.org Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b In-reply-to: <20030821140139.C57728-100000@megazone.bigpanda.com> References: <20030821140139.C57728-100000@megazone.bigpanda.com> Comments: In-reply-to Stephan Szabo message dated "Thu, 21 Aug 2003 14:07:08 -0700" Date: Sun, 24 Aug 2003 17:37:14 -0400 Message-ID: <5913.1061761034@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/1042 X-Sequence-Number: 42699 Stephan Szabo writes: > Well, if you want to be safer, I guess you could (at runtime) decide that > the table's gotten too big and fall back to the old method if you didn't > entirely rip it out. I'm not sure if that'd be too ugly though, but it > would mean that you wouldn't have to worry about it returning too many > tuples. I did it this way --- it falls back to the old code if the TID hash table grows to exceed SortMem. Should be noticeably faster than the old code for reasonably-sized IN lists. regards, tom lane