Re: Bad optimizer data for xml (WAS: xml data type implications of no =)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bad optimizer data for xml (WAS: xml data type implications of no =)
Дата
Msg-id 24204.1276093061@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bad optimizer data for xml (WAS: xml data type implications of no =)  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Ответы Re: Bad optimizer data for xml (WAS: xml data type implications of no =)
Список pgsql-bugs
Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes:
> It seems that the nub of this issue is that there are conceptually two
> types of =, one for datatype specific comparison, and one for optimizer
> statistical information calculation. However the system allows only the
> first, so if you don't (or can't) have one then you lose some possibly
> important optimization data.

Nonsense.  ANALYZE and the optimizer work with the datatype's usual
notion of '=', whatever it is.

It's possible that we should install a simplified code path in analyze.c
that can collect width data for a column even in the absence of any '='
operator.  I'm less than convinced that it's worth the trouble though.
Do you have an actual example where such data would have affected a
plan choice?

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: Invalid YAML output from EXPLAIN
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5495: RI/FK on self and inherited table