To: Joe Conway <mail@joeconway.com>
Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>,
	Dani Oderbolz <oderbolz@ecologic.de>, pgsql-hackers@postgresql.org
Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b 
In-reply-to: <3F45414A.6030301@joeconway.com> 
References: <20030821102627.C51705-100000@megazone.bigpanda.com>
	<25062.1061498540@sss.pgh.pa.us> <3F45414A.6030301@joeconway.com>
Comments: In-reply-to Joe Conway <mail@joeconway.com>
	message dated "Thu, 21 Aug 2003 15:01:46 -0700"
Date: Thu, 21 Aug 2003 18:17:55 -0400
Message-ID: <29873.1061504275@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> I'm toying with the notion of ripping out that logic and instead
>> building an in-memory hashtable of already-returned TIDs.  This could
>> theoretically run out of memory if the multiple indexscan returns enough
>> tuples, but I think in practice that wouldn't happen because the planner
>> wouldn't choose an indexscan when very large numbers of tuples are being
>> selected.

> I thought with your recent changes, you could use dynahash, which 
> already spills to disk instead of consuming all memory?

I was going to use dynahash, but it doesn't spill to disk.  You're
confusing that with the HashJoin mechanism, which is quite different and
only really useful for joins.

			regards, tom lane