Re: Problem with index in OR'd expression

Поиск
Список
Период
Сортировка
Искать
От
Ragnar
Тема
Re: Problem with index in OR'd expression
Дата
Msg-id
1167240470.6369.328.camel@localhost.localdomain
Ответ на
Список
Дерево обсуждения
Problem with index in OR'd expression postgresql.org@tgice.com
Re: Problem with index in OR'd expression Tom Lane <tgl@sss.pgh.pa.us>
Re: Problem with index in OR'd expression postgresql.org@tgice.com
Re: Problem with index in OR'd expression postgresql.org@tgice.com
Re: Problem with index in OR'd expression Tom Lane <tgl@sss.pgh.pa.us>
Re: Problem with index in OR'd expression postgresql.org@tgice.com
Re: Problem with index in OR'd expression Ragnar <gnari@hive.is>
Re: Problem with index in OR'd expression postgresql.org@tgice.com
Re: Problem with index in OR'd expression Ragnar <gnari@hive.is>
Re: Problem with index in OR'd expression Tom Lane <tgl@sss.pgh.pa.us>
On mið, 2006-12-27 at 11:02 -0600, postgresql.org@tgice.com wrote:
> 
> I was referring to the situation where one has this in a WHERE clause:
> 
>    ((vConstant IS NULL) OR (Table.IndexedCol = vConstant))
> 
> where vConstant is a *constant* parameter in a pl/pgsql function.

Reguardless of the issue whether pl/pgsql could be expected to
optimize this case, I find it difficult to imagine a scenario
where this kind of coding makes sense.

I understand that in some cases on would like to do this with
a *variable* to simplify logic, but what possible gain can
be had from doing this with a constant, other that obfuscation?

It does not make sense to spend CPU-time on  optimizing a case
that is not useful or common.

gnari


В списке pgsql-general по дате отправления
От: A. Kretschmer
Дата:
Сообщение: Re: Is PostgreSQL for this?
От: Tom Lane
Дата:
FAQ