On 10/06/10 02:17, Tom Lane wrote:
Mark Kirkwood<mark.kirkw...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
