Re: Transforming IN (...) to ORs, volatility
От | Heikki Linnakangas |
---|---|
Тема | Re: Transforming IN (...) to ORs, volatility |
Дата | |
Msg-id | 4D9B3859.8080708@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Transforming IN (...) to ORs, volatility (Marti Raudsepp <marti@juffo.org>) |
Ответы |
Re: Transforming IN (...) to ORs, volatility
|
Список | pgsql-hackers |
On 05.04.2011 13:19, Marti Raudsepp wrote: > On Fri, Apr 1, 2011 at 14:24, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> We sometimes transform IN-clauses to a list of ORs: >> >> postgres=# explain SELECT * FROM foo WHERE a IN (b, c); >> QUERY PLAN >> Seq Scan on foo (cost=0.00..39.10 rows=19 width=12) >> Filter: ((a = b) OR (a = c)) >> >> But what if you replace "a" with a volatile function? It doesn't seem legal >> to do that transformation in that case, but we do it: >> >> postgres=# explain SELECT * FROM foo WHERE (random()*2)::integer IN (b, c); >> QUERY PLAN >> >> Seq Scan on foo (cost=0.00..68.20 rows=19 width=12) >> Filter: ((((random() * 2::double precision))::integer = b) OR (((random() >> * 2::double precision))::integer = c)) > > Is there a similar problem with the BETWEEN clause transformation into > AND expressions? > > marti=> explain verbose select random() between 0.25 and 0.75; > Result (cost=0.00..0.02 rows=1 width=0) > Output: ((random()>= 0.25::double precision) AND (random()<= > 0.75::double precision)) Yes, good point. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: