On Thu, Dec 18, 2014 at 4:13 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 10/22/2014 01:55 PM, Teodor Sigaev wrote:
>>
>> Suggested patch adds GIN support contains operator for ranges over scalar
>> column.
>>
>> It allows more effective GIN scan. Currently, queries like
>> SELECT * FROM test_int4 WHERE i <= 1 and i >= 1
>> will be excuted by GIN with two scans: one is from mines infinity to 1 and
>> another is from -1 to plus infinity. That's because GIN is "generalized"
>> and it
>> doesn't know a semantics of operation.
>>
>> With patch it's possible to rewrite query with ranges
>> SELECT * FROM test_int4 WHERE i <@ '[-1, 1]'::int4range
>> and GIN index will support this query with single scan from -1 to 1.
>>
>> Patch provides index support only for existing range types: int4, int8,
>> numeric,
>> date and timestamp with and without time zone.
>
>
> I started to look at this, but very quickly got carried away into
> refactoring away the macros. Defining long functions as macros makes
> debugging quite difficult, and it's not nice to read or edit the source code
> either.
>
> I propose the attached refactoring (it doesn't include your range-patch yet,
> just refactoring the existing code). It turns the bulk of the macros into
> static functions. GIN_SUPPORT macro still defines the datatype-specific
> functions, but they are now very thin wrappers that just call the
> corresponding generic static functions.
>
> It's annoying that we need the concept of a leftmost value, for the < and <=
> queries. Without that, we could have the support functions look up the
> required datatype information from the type cache, based on the datatype of
> the passed argument. Then you could easily use the btree_gin support
> functions also for user-defined datatypes. But that needs bigger changes,
> and this is a step in the right direction anyway.
I just had a look at the refactoring patch and ISTM that this is a
good step forward in terms of readability. Teodor, I am noticing that
your patch cannot apply once the refactoring is done. Could you rebase
your patch once the refactoring is pushed?s
--
Michael