Re: Bad optimizer data for xml (WAS: xml data type implications of no =) - Mailing list pgsql-bugs

From Mark Kirkwood
Subject Re: Bad optimizer data for xml (WAS: xml data type implications of no =)
Date
Msg-id 4C100FA3.8050408@catalyst.net.nz
Whole thread Raw
In response to Re: Bad optimizer data for xml (WAS: xml data type implications of no =)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: John R Pierce
Date:
Subject: Re: BUG #5496: Link does not open though wish to use following site
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading