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
Ответ на
Re: Problem with index in OR'd expression (postgresql.org@tgice.com)
Список
Дерево обсуждения
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 по дате отправления