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
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() |