| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Dani Oderbolz <oderbolz(at)ecologic(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [SQL] "SELECT IN" Still Broken in 7.4b |
| Date: | 2003-08-21 22:17:55 |
| Message-ID: | 29873.1061504275@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-sql |
Joe Conway <mail(at)joeconway(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manfred Koizar | 2003-08-21 22:24:39 | Re: Decent VACUUM (was: Buglist) |
| Previous Message | Joe Conway | 2003-08-21 22:01:46 | Re: [SQL] "SELECT IN" Still Broken in 7.4b |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Drew Wilson | 2003-08-22 00:21:47 | logging messages from inside pgPLSQL routine? |
| Previous Message | Joe Conway | 2003-08-21 22:01:46 | Re: [SQL] "SELECT IN" Still Broken in 7.4b |