I wrote:
> I did a little bit of performance testing on an x86_64 machine (Fedora 14),
> and found that the time to execute a clause like
> 	WHERE int4range(1,2) -|- int4range(x, 10000000)
> (x being an integer Var) grows from 0.37 us to 0.56 us if we adopt the
> patched version of range_adjacent.  With float8 ranges it grows from
> 0.35 us to 0.54 us.  So these are noticeable penalties but they don't
> seem like show-stoppers.  Since the alternative is to document that
> the apparent freedom to choose a canonicalization policy is illusory,
> I'm inclined to think we should change it.

It occurred to me that we can easily buy back the extra time for range
types that don't have a canonical function (ie, continuous ranges).
If there's no such function, it's impossible for B..C to normalize to
empty when B < C, so we can skip the extra logic.  The attached version
is no slower than the original code for continuous ranges, and doesn't
seem measurably different from my previous patch for discrete ranges.

			regards, tom lane

In response to

• Re: range_adjacent and discrete ranges at 2011-11-23 21:10:04 from Tom Lane

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2011-11-23 21:55:29
	Subject: Re: Not HOT enough
Previous:	From: Simon Riggs	Date: 2011-11-23 21:36:46
	Subject: Re: Not HOT enough