Re: IN optimization in 7.2 ?????
От | Shane Wright |
---|---|
Тема | Re: IN optimization in 7.2 ????? |
Дата | |
Msg-id | 200202181742.g1IHgjF15327@fullerruss.dsvr.co.uk обсуждение исходный текст |
Ответ на | Re: IN optimization in 7.2 ????? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-general |
IIRC, the subselect is executed only once, but using IN (...) can be slow for large result sets because the searching in IN is just a sequential scan of that result set. Not sure why it'd be faster to crop of the first and last ones though.. -- Shane On Monday 18 Feb 2002 3:42 pm, Bruce Momjian wrote: > hubert depesz lubaczewski wrote: > > On Mon, Feb 18, 2002 at 09:52:19AM -0500, Bruce Momjian wrote: > > > Not that I know of. > > > > strange. what could lead to this results then? > > i used to think that IN (SELECT ...) is the slowest possible way at all. > > > > depesz > > > > p.s. of course both select's use indices, and table is vacuumed > > I have always wondered this too. Seems IN evaluates the entire query > while EXISTS evaluates it for each row, or at least that is how I > understand it, so saying EXISTS is always faster may be wrong. > Comments?
В списке pgsql-general по дате отправления: