Transforming IN (...) to ORs, volatility
От | Heikki Linnakangas |
---|---|
Тема | Transforming IN (...) to ORs, volatility |
Дата | |
Msg-id | 4D95B605.2020709@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: Transforming IN (...) to ORs, volatility
Re: Transforming IN (...) to ORs, volatility Re: Transforming IN (...) to ORs, volatility Re: Transforming IN (...) to ORs, volatility |
Список | pgsql-hackers |
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)) (2 rows) 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)) (2 rows) I tried to read the SQL spec to see if it has anything to say about that, but I couldn't find anything. My common sense says that that transformation is not legal. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: