[HACKERS] gist access methods parameter types
If I have this sql composite type: CREATE TYPE d_type AS ( i integer, e integer, id integer ); and this table: CREATE TABLE my_tab ( d_col d_type NOT NULL ) CREATE INDEX my_tab_d_col_gist ON my_tab USING gist (d_col); I am implementing consistent, union, compress, decompress, penalty, picksplit and same. CREATE OPERATOR CLASS d_type_ops DEFAULT FOR TYPE d_type USING gist AS FUNCTION 1 d_type_consistent(internal, d_type, smallint, oid, internal), FUNCTION 2 d_type_union(internal, internal), FUNCTION 3 d_type_compress(internal), FUNCTION 4 d_type_decompress(internal), FUNCTION 5 d_type_penalty(internal, internal, internal), FUNCTION 6 d_type_picksplit(internal, internal), FUNCTION 7 d_type_same(internal, internal, internal); The problem is that some of these methods take as input parameters the d_type and some the struct type that I internally implemented in c (which will be saved to the tree). If I understand correctly consistent and compress are the only functions that will have input parameter of d_type. The others will have my c internal type. *Is this correct?* Something else, will a non-leaf node have one entry that will be produced by union? I am asking because I want the leaf node entries to be of different type from non-leaf node entries (the difference between them is that non-leaf entry will not keep the id attribute). Thank you in advance.
Re: [HACKERS] gist access methods parameter types
On Mon, Sep 27, 2010 at 4:26 AM, Marios Vodas mvo...@gmail.com wrote: The problem is that some of these methods take as input parameters the d_type and some the struct type that I internally implemented in c (which will be saved to the tree). If I understand correctly consistent and compress are the only functions that will have input parameter of d_type. The others will have my c internal type. Is this correct? It looks to me like you need to read the documentation on this topic. http://www.postgresql.org/docs/current/static/gist-implementation.html From what I can gather from said documentation, consistent will indeed get the data type as an argument, but compress does not. You might also want to look at contrib/btree_gist. Something else, will a non-leaf node have one entry that will be produced by union? I believe that's correct. I am asking because I want the leaf node entries to be of different type from non-leaf node entries (the difference between them is that non-leaf entry will not keep the id attribute). Thank you in advance. I don't think this is a good idea. I suspect you want to keep the id attribute never, and use the recheck stuff. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gist access methods parameter types
Marios Vodas mvo...@gmail.com writes: I am implementing consistent, union, compress, decompress, penalty, picksplit and same. […] The problem is that some of these methods take as input parameters the d_type and some the struct type that I internally implemented in c (which will be saved to the tree). That shouldn't be a problem as you're going to implement the functions in C too, I guess. After all an index is all about performances. http://www.postgresql.org/docs/current/static/gist-implementation.html http://wiki.postgresql.org/wiki/Image:Prato_2008_prefix.pdf Please not that the documentation here has been true in 8.3 too but didn't get backpatched there. Maybe we should consider? If I understand correctly consistent and compress are the only functions that will have input parameter of d_type. The others will have my c internal type. Is this correct? Well how is your C coded type different from d_type and why? Something else, will a non-leaf node have one entry that will be produced by union? I am asking because I want the leaf node entries to be of different type from non-leaf node entries (the difference between them is that non-leaf entry will not keep the id attribute). Non-leaf nodes will contain a page full of entries all consistent with each-other and sharing a common union. You can have leaf nodes entries of a different type with the STORAGE option of the CREATE OPERATOR CLASS command here, and the compress() and decompress() methods: http://www.postgresql.org/docs/current/static/sql-createopclass.html Then you have to take care about that in several of the functions in the GiST API, in particular in consistent, see the GIST_LEAF(entry) macro. Your main source of documentation at this point lies in the source of the different GiST implementations, see ip4r, period, prefix and some more. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gist access methods parameter types
Let me explain better what I want to do.
I want to have the types in sql level (composite types) like this:
--Spatio-Temporal Position in 3 Dimensions(cartessian x, cartessian y, time)
CREATE TYPE pos3d AS
(
x double precision,
y double precision,
t timestamp
);
--Spatio-Temporal Delta (comes from Δ, meaning alteration/change)
--i stands for (i)nitial position
--e stands for (e)nding position
--trajectory holds the id of the trajectory in which the current delta
belongs to
CREATE TYPE delta3d AS
(
i pos3d,
e pos3d,
trajectory integer
);
Having them in sql level eases my work much more than having them as base
types in C. But I need an index to speed up some operations. So I build two
types in C just for indexing purposes:
typedef struct {
float8 xi, yi;
Timestamp ti;
float8 xe, ye;
Timestamp te;
int32 trajectory;
} delta3d;
typedef struct {
float8 xl, yl;
Timestamp tl;
float8 xh, yh;
Timestamp th;
} delta3d_mbb;
As you see the first is a replica of my sql type in C and the second misses
some information (it is just the minimum bounding box which means that we
don't know initial/ending positions neither the trajectory id). The second
type is intended for non-leaf nodes while the first for leaf nodes.
My implementation of the tree is a kind of 3D-Rtree.
Now I am a little confused about the type of the arguments that each access
method (consistent, union, compress, decompress, penalty, picksplit, same)
requires in order to accomplish my goal.
Another black spot I have regarding compress.
If the entry passed to compress is a leaf entry then it is going to be of
sql type (composite type) delta3d (meaning I will get the values using
tuples etc). Correct? If not of what type is it going to be?
Assume it is a non-leaf entry. In that case of what type will it be? If it
is delta3d_mbb (C type) then I don't have to change it. But is it going to
be?
I am sorry if I seem importunate, but it has only been 2 weeks since I
started messing with postgresql C extensions, and I need help...
Re: [HACKERS] gist access methods parameter types
On Mon, Sep 27, 2010 at 10:37 AM, Marios Vodas mvo...@gmail.com wrote: Let me explain better what I want to do. I want to have the types in sql level (composite types) like this: --Spatio-Temporal Position in 3 Dimensions(cartessian x, cartessian y, time) Have you looked at PostGIS? As you see the first is a replica of my sql type in C and the second misses some information (it is just the minimum bounding box which means that we don't know initial/ending positions neither the trajectory id). The second type is intended for non-leaf nodes while the first for leaf nodes. Yeah, I still don't think that's the right way to do it. Storing the bounding box seems right, but just do that for all the nodes. It's probably worth looking at the implementation of these functions for, say, the existing point, box, and polygon datatypes, which have similar issues. My implementation of the tree is a kind of 3D-Rtree. Now I am a little confused about the type of the arguments that each access method (consistent, union, compress, decompress, penalty, picksplit, same) requires in order to accomplish my goal. Another black spot I have regarding compress. If the entry passed to compress is a leaf entry then it is going to be of sql type (composite type) delta3d (meaning I will get the values using tuples etc). Correct? If not of what type is it going to be? According to the documentation, no. It takes a GISTENTRY and returns a GISTENTRY. But you can extract the relevant key out of there. The best way to do this, again, is to look at existing examples, like gist_poly_compress. Assume it is a non-leaf entry. In that case of what type will it be? If it is delta3d_mbb (C type) then I don't have to change it. But is it going to be? I am sorry if I seem importunate, but it has only been 2 weeks since I started messing with postgresql C extensions, and I need help... If you need a moderate amount of help, you can probably get it the way that you have been: asking questions. If you need more help than that, see http://www.postgresql.org/support/professional_support -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gist access methods parameter types
Have you looked at PostGIS? Yes ofcourse, I also read everything in postgresql official documentation plus http://gist.cs.berkeley.edu/pggist/opcltour.html. Yeah, I still don't think that's the right way to do it. Storing the bounding box seems right, but just do that for all the nodes. It's probably worth looking at the implementation of these functions for, say, the existing point, box, and polygon datatypes, which have similar issues. I intend to change the structure I describe in the future. So if it is not wrong and harmful to the implementation I want to keep that extra info in leaf node entries. I have read src/backend/access/gist/gistproc.c I am aware of what it does. According to the documentation, no. It takes a GISTENTRY and returns a GISTENTRY. But you can extract the relevant key out of there. The best way to do this, again, is to look at existing examples, like gist_poly_compress. Exactly what I am saying. I extract the key out of GISTENTRY of course but that key has to contain a value of some type. And my question is of what type if it is a leaf and of what if it is not a leaf entry? Thank you for helping.
Re: [HACKERS] gist access methods parameter types
Please can you answer the question of whether entry-key in compress should
be of delta3d sql type (composite type) and if not of what it should be
since the type I index is different from the type stored in tree?
Taking into consideration the types I described before this is my code for
compress.
Datum delta3d_compress(PG_FUNCTION_ARGS) {
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
GISTENTRY *retval;
HeapTupleHeader in;
HeapTupleHeader i;
HeapTupleHeader e;
bool isnull;
if (entry-leafkey) {
in = DatumGetHeapTupleHeader(entry-key);
if (in != NULL) {
i = DatumGetHeapTupleHeader(GetAttributeByName(in, i,
isnull));
e = DatumGetHeapTupleHeader(GetAttributeByName(in, e,
isnull));
delta3d *compressed_data = (delta3d *) palloc(sizeof (delta3d));
compressed_data-xi = DatumGetFloat8(GetAttributeByName(i, x,
isnull));
compressed_data-yi = DatumGetFloat8(GetAttributeByName(i, y,
isnull));
compressed_data-ti = DatumGetTimestamp(GetAttributeByName(i,
t, isnull));
compressed_data-xe = DatumGetFloat8(GetAttributeByName(e, x,
isnull));
compressed_data-ye = DatumGetFloat8(GetAttributeByName(e, y,
isnull));
compressed_data-te = DatumGetTimestamp(GetAttributeByName(e,
t, isnull));
compressed_data-trajectory =
DatumGetInt32(GetAttributeByName(in, trajectory, isnull));
retval = palloc(sizeof (GISTENTRY));
gistentryinit(*retval, PointerGetDatum(compressed_data),
entry-rel, entry-page, entry-offset, FALSE);
} else {
retval = palloc(sizeof (GISTENTRY));
gistentryinit(*retval, (Datum) 0, entry-rel, entry-page,
entry-offset, FALSE);
}
} else {
retval = entry; *//does this have to change? I thing it is going to
be of C type delta3d_mbb, am I right?*
}
PG_RETURN_POINTER(retval);
}
