Re: range_adjacent and discrete ranges - Mailing list pgsql-hackers

From Tom Lane
Subject Re: range_adjacent and discrete ranges
Date
Msg-id 3634.1322082604@sss.pgh.pa.us
Whole thread Raw
In response to Re: range_adjacent and discrete ranges  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: range_adjacent and discrete ranges
List 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 likeWHERE 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Not HOT enough
Next
From: Simon Riggs
Date:
Subject: Re: Not HOT enough