From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | 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-24 21:37:14 |
Message-ID: | 5913.1061761034@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-24 22:39:18 | Re: Single-file DBs WAS: Need concrete 'Why Postgres |
Previous Message | Tom Lane | 2003-08-24 21:27:28 | Re: ambiguous sql states |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-24 21:38:16 | Re: "SELECT IN" Still Broken in 7.4b |
Previous Message | Peter Eisentraut | 2003-08-24 21:10:24 | Re: Which cursor-related warnings should be errors? |