Re: GiST consistent function, expected arguments; multi-dimensional indexes

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Eric <fishware(at)comcast(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: GiST consistent function, expected arguments; multi-dimensional indexes
Date: 2007-06-27 18:00:36
Message-ID: 20070627180036.GC22179@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 27, 2007 at 09:32:13AM -0700, Eric wrote:
> In GiST, for each new data type we support we're expected to provide
> (among other things) a function to determine whether a query is
> consistent with a particular index entry (given an operator/
> strategy). I haven't been able to figure out when the query value
> being passed (arg 1 in the <datatype>_consistent function) is the
> actual value (say the value "6"), or a pointer to the value. In the
> btree_gist contrib examples, I see both cases (int4, a value; text, a
> pointer). Does anyone know how to tell when when the gist consistent
> function should expect a pointer or a value (apparently this is setup
> in the scankey in a generic fashion before getting into the index-
> specific implementation but can't tell how exactly)? Does this depend
> on the storage clause in CREATE TYPE?

Everything is always passed as a Datum, so yes, it's is determined by
the storage clause in CREATE TYPE.

> Also, a broader question. GiST is setup to evaluate each column in
> the index in the order it was specified (e.g. if the index has colX,
> colY, then if colX satisfies the search, colX is checked, otherwise
> colY is ignored)...as in traditional btree indexes. I would like to
> set up a multi-dimensional index that doesn't require all data to be
> contained in a single column (like an rtree index where the X and Y
> coordinates would be in different columns rather than a single
> composite column).

The usual approach to this is to define the index on a composite of
the values. For example, if you have a table with two points that you
want to index together, you do:

CREATE INDEX foo ON bar((box(point1,point2)));

i.e. a functional index on the result of combining the points. It does
mean you need to use the same syntax when doing the queries, but it
works with modifying any internal code at all...

Given you can use rowtypes more easily these days, it's quite possible
you use build an operator class on a row type...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2007-06-27 18:31:34 Re: R: [postgresql-it] no cascade triggers?
Previous Message Heikki Linnakangas 2007-06-27 17:42:05 Re: self defined data type "with limit"?