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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
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 14:17:41
Message-ID: 24204.1276093061@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2010-06-09 14:32:05 Re: BUG #5495: RI/FK on self and inherited table
Previous Message Dean Rasheed 2010-06-09 13:35:40 Re: Invalid YAML output from EXPLAIN