Re: range_adjacent and discrete ranges
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Florian Pflug <fgp@phlo.org>, Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-11-23T21:10:04Z
Lists: pgsql-hackers
I wrote: > Attached is a draft patch for this. It passes regression tests but I've > not tried to exercise it with a canonical function that actually does > something different. I hacked up int4range_canonical to produce []-style ranges, and confirmed that this version of range_adjacent seems to work with them. > It's going to be a bit slower than Jeff's > original, because it does not only range_cmp_bound_values but also a > make_range cycle (in most cases). So I guess the question is how much > we care about supporting canonical functions with non-default policies. > Thoughts? 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. regards, tom lane