From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Cause of intermittent rangetypes regression test failures |
Date: | 2011-11-14 07:32:18 |
Message-ID: | 1321255938.25053.12.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2011-11-13 at 15:38 -0500, Tom Lane wrote:
> If the table has been analyzed, then the
> most_common_values array for column ir will consist of
> {empty}
> which is entirely correct since that value accounts for 16% of the
> table. And then, when mcv_selectivity tries to estimate the selectivity
> of the << condition, it applies range_before to the empty range along
> with the int4range(100,500) value, and range_before spits up.
>
> I think this demonstrates that the current definition of range_before is
> broken. It is not reasonable for it to throw an error on a perfectly
> valid input ... at least, not unless you'd like to mark it VOLATILE so
> that the planner will not risk calling it.
>
> What shall we have it do instead?
We could have it return NULL, I suppose. I was worried that that would
lead to confusion between NULL and the empty range, but it might be
better than marking it VOLATILE.
Thoughts, other ideas?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2011-11-14 08:06:30 | Re: SQLDA fix for ECPG |
Previous Message | Greg Smith | 2011-11-14 04:42:30 | pg_stat_statements with query tree based normalization |