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

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bad optimizer data for xml (WAS: xml data type implications of no =)
Date: 2010-06-09 22:03:15
Message-ID: 4C100FA3.8050408@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 10/06/10 02:17, Tom Lane wrote:
> Mark Kirkwood<mark(dot)kirkwood(at)catalyst(dot)net(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Gardner 2010-06-09 22:21:18 BUG #5497: plpythonu gives cache lookup error
Previous Message Tom Lane 2010-06-09 21:34:34 Re: [BUGS] Server crash while trying to read expression using pg_get_expr()