Re: [SQL] "SELECT IN" Still Broken in 7.4b

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: Whole Thread | Raw Message | 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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-sql by date

  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?