| From: | Shane Wright <me(at)shanewright(dot)co(dot)uk> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: IN optimization in 7.2 ????? |
| Date: | 2002-02-18 17:42:58 |
| Message-ID: | 200202181742.g1IHgjF15327@fullerruss.dsvr.co.uk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | eric | 2002-02-18 18:03:07 | execute permissions of stored procedures? |
| Previous Message | Richard Emberson | 2002-02-18 17:38:41 | postgresql mail server and archiving software |