Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: Tom Lane <tgl@sss.pgh.pa.us>, Stephan Szabo <sszabo@megazone.bigpanda.com>
Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b
Date: Thu, 21 Aug 2003 14:19:47 -0700
User-Agent: KMail/1.4.3
Cc: Dani Oderbolz <oderbolz@ecologic.de>,
	pgsql-hackers@postgresql.org
References: <20030821102627.C51705-100000@megazone.bigpanda.com>
	<25062.1061498540@sss.pgh.pa.us>
In-Reply-To: <25062.1061498540@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200308211419.47226.josh@agliodbs.com>

Tom,

> 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.

Don't forget all of the tyros who tune their queries through "set=20
enable_seqscan=3Dfalse".  I think we'd need some kind of memory safety valv=
e on=20
this, like sandboxing it in sort_mem.

--=20
-Josh Berkus
 Aglio Database Solutions
 San Francisco