From: | "Bart Degryse" <Bart(dot)Degryse(at)indicator(dot)be> |
---|---|
To: | "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com> |
Cc: | <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Function returns error (view) |
Date: | 2008-02-27 09:16:51 |
Message-ID: | 47C53892.A3DD.0030.0@indicator.be |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
For rather "simple" queries like this one PostgreSQL indeed seems to be quite smart.
I have quite a lot of statements where it does make a difference though (PostgreSQL 8.2.4).
As long as I have one statement where it makes a difference I will use the join
rather than the IN(subselect) just to be sure of optimal performance.
Keeping that in mind I don't see any harm in advising others to do so too.
But you're right in stating that it's not always necessary.
>>> "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com> 2008-02-27 10:09 >>>
2008/2/27, Bart Degryse <Bart(dot)Degryse(at)indicator(dot)be>:
>
> I would also suggest you replace the
> ...t.cod_user IN (subselect)
> by a join construction. I think it's more performant.
In recent versions PostgreSQL is quite smart when planning IN, so that
shouldn't be a concern.
Markus
--
Markus Bertheau
Blog: http://www.bluetwanger.de/blog/
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Scheidegger | 2008-02-27 09:25:59 | REFERENCES and INHERITS restrictions? |
Previous Message | Markus Bertheau | 2008-02-27 09:09:54 | Re: Function returns error (view) |