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  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: Set hint bits upon eviction from BufMgr