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