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