Could anyone familiar with the pg version of GiST tell me if the
framework allows entries in the tree as non-uniform sizes (in other
words, variable-length keys)? I want to write an extension for a
TV-tree, but this is an essential component.
Thanks;
Eric Redmond
---(end
Yes, our GiST supports variable-length keys.
Take a look on http://www.sai.msu.su/~megera/postgres/gist/
Oleg
On Wed, 17 Jul 2002, Eric Redmond wrote:
Could anyone familiar with the pg version of GiST tell me if the
framework allows entries in the tree as non-uniform sizes (in other
I've been doing some research work using the GiST indexes,
but I persistently develop a problem where the system doesn't
make use of the indexes during the execution of a query. If
I use the examples provided here:
http://wit.mcs.anl.gov/~selkovjr/pg_extensions/
For instance, and I
David,
could you provide more info (scheme, query, postgresql version)
Regards,
Oleg
On Sat, 5 May 2001, David McWherter wrote:
I've been doing some research work using the GiST indexes,
but I persistently develop a problem where the system doesn't
make use of
Sure. My postgresql version is 7.0.2.
My database has a datatype called graph that looks like this:
CREATE TYPE graph (
internallength = VARIABLE,
input = graph_in,
output = graph_out
);
CREATE OPERATOR ~ (
leftarg = graph,
rightarg = graph,
David,
GiST prior 7.1 was broken in several respects. Please,
try 7.1 and examples from contrib/intarray. It should works.
btw, you'll have compress function actually works.
Regards,
Oleg
On Sat, 5 May 2001, David McWherter wrote:
Sure. My postgresql version is
David McWherter [EMAIL PROTECTED] writes:
I've tried adding the parameters 'restrict = eqsel' and 'join = eqjoinsel'
to the datatype operators, but that doesn't seem to change anything.
You might have better luck if you use area-related selectivity
estimators. Your problem seems to be that
So, I've migrated my code to do the TOAST'ing thing required of 7.1
clients, and I've updated my operator to use the areaselectors:
CREATE OPERATOR = (
leftarg = graph,
rightarg = graphrange,
procedure = graph_inrange,
commutator = '=',
Beautiful! That fixed my problem. One thing that might be
useful is to update the Index method-extension documentation
on the web site to reflect this problem a bit...if somebody
just wants to get a working index, it can be a bit misleading.
I'll probably go and see if I can construct a few
