Universal B-tree
Dear developers,
I'm PhD candidate in Brazil and a newbie on postgresql developement, sorry
for any silly questions. I implemented a new algorithm for range search
using universal b-tree but I don't have a clue how to integrate it into
postgresql.
Where I can find the resources about it?
I don't need to change B-tree estructure. I just need integrate my encode
function that transforms multiple keys into one key by bit-interleaving and
to acess elements given several intervals (range search).
I've heard about a framework ATOM on the article "Native Multidimensional
Indexing in Relational Databases" written by David Hoksza, Tomas Skopal
which says that ATOM abstracts the way that postgres records information...
does any one know where I can get it?
Best regards,
Daniel Oliveira
On Mon, Aug 9, 2010 at 5:31 PM, Daniel Oliveira
<danielmarquesoliveira@gmail.com> wrote:
I don't need to change B-tree estructure. I just need integrate my encode
function that transforms multiple keys into one key by bit-interleaving and
to acess elements given several intervals (range search).
You could build a "expression" index on the function which will build
a regular btree. Then any range clause on a similar expression in the
query would be able to use the index. Postgres is capable of detecting
multiple range clauses that can use one or more indexes and combine
the results. It might not be perfect for your use case, being a
general purpose tool.
I'm not sure how feasible it would be to implement a special purpose
case that matches your needs. Perhaps a special index type and index
access method similar to gist "tsquery" data type. But that's a lot
more work and a lot more C coding.
--
greg
For research purpose, I think that expression index is a good idea. I just
want to do a proof of concept.
The other issue is that my algorithm break a z-order interval into several
intervals that represents the query box. How should I create it without
creating any overhead?
Best regards,
daniel
2010/8/9 Greg Stark <gsstark@mit.edu>
Show quoted text
On Mon, Aug 9, 2010 at 5:31 PM, Daniel Oliveira
<danielmarquesoliveira@gmail.com> wrote:I don't need to change B-tree estructure. I just need integrate my encode
function that transforms multiple keys into one key by bit-interleavingand
to acess elements given several intervals (range search).
You could build a "expression" index on the function which will build
a regular btree. Then any range clause on a similar expression in the
query would be able to use the index. Postgres is capable of detecting
multiple range clauses that can use one or more indexes and combine
the results. It might not be perfect for your use case, being a
general purpose tool.I'm not sure how feasible it would be to implement a special purpose
case that matches your needs. Perhaps a special index type and index
access method similar to gist "tsquery" data type. But that's a lot
more work and a lot more C coding.--
greg
There is a way to acess a index inside a c function without using a sql
statement ?
Best regards,
Daniel Oliveira
2010/8/9 Daniel Oliveira <danielmarquesoliveira@gmail.com>
Show quoted text
For research purpose, I think that expression index is a good idea. I just
want to do a proof of concept.The other issue is that my algorithm break a z-order interval into several
intervals that represents the query box. How should I create it without
creating any overhead?Best regards,
daniel
2010/8/9 Greg Stark <gsstark@mit.edu>
On Mon, Aug 9, 2010 at 5:31 PM, Daniel Oliveira
<danielmarquesoliveira@gmail.com> wrote:
I don't need to change B-tree estructure. I just need integrate my
encode
function that transforms multiple keys into one key by bit-interleaving
and
to acess elements given several intervals (range search).
You could build a "expression" index on the function which will build
a regular btree. Then any range clause on a similar expression in the
query would be able to use the index. Postgres is capable of detecting
multiple range clauses that can use one or more indexes and combine
the results. It might not be perfect for your use case, being a
general purpose tool.I'm not sure how feasible it would be to implement a special purpose
case that matches your needs. Perhaps a special index type and index
access method similar to gist "tsquery" data type. But that's a lot
more work and a lot more C coding.--
greg
