From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: range_adjacent and discrete ranges |
Date: | 2011-11-23 21:10:04 |
Message-ID: | 3634.1322082604@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-11-23 21:36:46 | Re: Not HOT enough |
Previous Message | Robert Haas | 2011-11-23 20:45:16 | Re: Not HOT enough |