Thread: 'alternatives'
In a query plan, I noticed the following:
Join Filter: (((all_permissions.role_recursive AND (alternatives: SubPlan 5 or hashed SubPlan 6)) OR
(permitted_e.id= deployed_e.id)) AND (NOT (SubPlan 13)))
What's the 'alternatives' line? Brand new to me!
--
-- Christophe Pettus
xof@thebuild.com
Hi Christophe, On 2012-11-28 13:07:12 -0800, Christophe Pettus wrote: > In a query plan, I noticed the following: > > Join Filter: (((all_permissions.role_recursive AND > (alternatives: SubPlan 5 or hashed SubPlan 6)) OR > (permitted_e.id = deployed_e.id)) AND (NOT (SubPlan 13))) Check the first item of http://www.postgresql.org/docs/current/interactive/release-9-2.html#AEN110503 Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Hi, Andres, Thanks! On Nov 28, 2012, at 1:58 PM, Andres Freund wrote: > http://www.postgresql.org/docs/current/interactive/release-9-2.html#AEN110503 Does that apply to views as well? (This particular plan was not from a prepared or PL/pgSQL statement, but did include views.) -- -- Christophe Pettus xof@thebuild.com
Hi, On 2012-11-28 14:16:18 -0800, Christophe Pettus wrote: > Thanks! Not much to thank for, the answer was actually wrong... > Does that apply to views as well? (This particular plan was not from a prepared or PL/pgSQL statement, but did includeviews.) Its not really relevant for views no. The real answer for this is that this actually a 8.4 feature not the aforementioned 9.2 feature. The commit introducing this is: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bd3daddaf232d95b0c9ba6f99b0170a0147dd8af What that does to add hashing support for IN(). But hashing can be pessimal in comparison to a explicit check if only a few values come in, so this can be checked at runtime after the above commit... Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes: > The commit introducing this is: > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bd3daddaf232d95b0c9ba6f99b0170a0147dd8af > What that does to add hashing support for IN(). But hashing can be > pessimal in comparison to a explicit check if only a few values come in, > so this can be checked at runtime after the above commit... Yeah. If you look at the subplans, one is designed for retail probes and the other is designed for sucking up the entire subquery result into a hashtable. EXPLAIN ANALYZE will show you that only one gets used at runtime. (The idea of dynamic switchover hasn't gotten anywhere yet.) regards, tom lane