On Mon, November 14, 2011 19:43, Tom Lane wrote:
> Jeff Davis writes:
>> On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote:
>
> While thinking about this ... would it be sensible for range_lower and
> range_upper to return NULL instead of throwing an exception for empty or
> infinite ranges? As w
Jeff Davis writes:
> On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote:
>> It needs to return FALSE, actually. After further reading I realized
>> that you have that behavior hard-wired into the range GiST routines,
>> and it's silly to make the stand-alone versions of the function act
>> differe
On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote:
> It needs to return FALSE, actually. After further reading I realized
> that you have that behavior hard-wired into the range GiST routines,
> and it's silly to make the stand-alone versions of the function act
> differently.
Good point. That ma
Jeff Davis writes:
> On Sun, 2011-11-13 at 15:38 -0500, Tom Lane wrote:
>> 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
>>
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 esti
Well, I was overthinking the question of why rangetypes sometimes fails
with
select count(*) from test_range_gist where ir << int4range(100,500);
! ERROR: input range is empty
Turns out that happens whenever auto-analyze has managed to process
test_range_gist before we get to this part of the
