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

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

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.  I'm less than convinced that it's worth the trouble though.
Do you have an actual example where such data would have affected a
plan choice?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Invalid YAML output from EXPLAIN
Next
From: Tom Lane
Date:
Subject: Re: BUG #5495: RI/FK on self and inherited table