Re: Bad optimizer data for xml (WAS: xml data type implications of no =)
От | Mark Kirkwood |
---|---|
Тема | Re: Bad optimizer data for xml (WAS: xml data type implications of no =) |
Дата | |
Msg-id | 4C100FA3.8050408@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: Bad optimizer data for xml (WAS: xml data type implications of no =) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On 10/06/10 02:17, Tom Lane wrote: > 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. > > Slow down the reading Tom... and read what I was actually saying - note the"conceptually". Of course the code uses the datatype's defined "=". > 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. > Yeah I was thinking along the same lines. > Do you have an actual example where such data would have affected a > plan choice? > > > Not at the moment, I was thinking that anywhere that used such datatypes in a subquery of similar might be a likely case. I guess I was looking at this as a case of "this is an area where we have less accurate optimizer data that we could have", and thinking of ways to improve it. regards Mark
В списке pgsql-bugs по дате отправления: