Re: Cause of intermittent rangetypes regression test failures

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

In response to

Responses

Browse pgsql-hackers by date

  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