Re: optimizing queries using IN and EXISTS

От: Nick Hofstede
Тема: Re: optimizing queries using IN and EXISTS
Дата: ,
Msg-id: BC885F9E3DB48248A4C9FC7F2C57215C2DAB0587@Hoefnix.dc.intranet
(см: обсуждение, исходный текст)
Ответ на: Re: optimizing queries using IN and EXISTS  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

optimizing queries using IN and EXISTS  (Nick Hofstede, )
 Re: optimizing queries using IN and EXISTS  (Peter Geoghegan, )
  Re: optimizing queries using IN and EXISTS  (Nick Hofstede, )
 Re: optimizing queries using IN and EXISTS  (Tom Lane, )
  Re: optimizing queries using IN and EXISTS  (Nick Hofstede, )

Interesting.
Thanks for the work-around.

Regards,

Nick

-----Original Message-----
From:  [mailto:] On Behalf Of Tom Lane
Sent: donderdag 19 juli 2012 0:36
To: Nick Hofstede
Cc: 
Subject: Re: [PERFORM] optimizing queries using IN and EXISTS

Nick Hofstede <> writes:
> I'm surprised at the difference in speed/execution plan between two
> logically equivalent queries, one using IN, the other using EXISTS.
> (At least I think they are logically equivalent)

> SELECT *
> FROM   foo
> WHERE  'text6' IN (SELECT value
>                    FROM   bar
>                           JOIN foo AS foo2
>                             ON bar.foo_ref = foo2.id
>                    WHERE  foo2.id = foo.id)

Hm.  convert_ANY_sublink_to_join() rejects subqueries that contain any Vars of the parent query level, so the reference
tofoo.id prevents this from being converted to a semijoin.  However, it seems like that's overly restrictive.  I'm not
surethat we could remove the test altogether, but at least outer vars used in WHERE seem safe. 

In the meantime, you can recast like this:

SELECT *
FROM   foo
WHERE  ('text6', id) IN (SELECT value, foo2.id
                   FROM   bar
                          JOIN foo AS foo2
                            ON bar.foo_ref = foo2.id)

and still get a semijoin plan from an IN-style query.

                        regards, tom lane

--
Sent via pgsql-performance mailing list ()
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


В списке pgsql-performance по дате сообщения:

От: mandavi
Дата:
Сообщение: Re: queries are fast after dump->restore but slow again after some days dispite vacuum
От: "mark"
Дата:
Сообщение: Deferred constraints performance impact ?