On Tue, Jan 4, 2011 at 1:18 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote:
>> > It doesn't allow for all of the suggested features. In particular, it
>> > would not allow "granules" to be specified for discrete ranges. But on
>> > balance, it seems like this is the most conceptually simple and I think
>> > it satisfies the primary use cases.
>>
>> Maybe I'm missing something, but it seems like this approach could
>> support granules. You just have to define the canonicalize function
>> in terms of the granule.
>
> I meant that it doesn't support them as an explicit, user-visible
> concept.
>
> The main drawback here is that only a select group of people will be
> defining discrete range types at all, because it would require them to
> define a function first. Perhaps that's for the best, because, (as Tom
> pointed out) we don't want someone using floats and then specifying a
> granule of '0.01'.
>
> While we're talking about it, one question I had is: should the
> canonicalize function be:
> /* works on the deserialized information right before serialization */
> canonical(&flags, &lower_bound, &upper_bound)
> or
> /* works on the serialized form right after serialization */
> range = canonical(range)
>
> I would lean toward the latter because it's simpler on the user (and
> allows non-C functions).
Yeah, me too.
> But perhaps an efficiency argument could be
> made for the former because it could avoid one round of
> deserialize/reserialize when the representation is not already in
> canonical form.
I believe this might be an appropriate time to apply Knuth's Law. I'm
not thrilled with the amount of palloc overhead we have in the
backend, but absent some evidence that this case is going to be
particularly significant, I'd be disinclined to contort the interface.I suspect that if you run oprofile this won't be
thebottleneck.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
