Interface of the R-tree in order to work with postgresql

On Mon, Oct 09, 2006 at 09:15:58AM -0500, jorge alberto wrote:

Hi everybody!
I'm Jorge from Peru South America, and this is my first post

I want to know how can I add a new spatial access method into the postgresql
(I'm doing research on spatial access methods( reading a lot of papers and
programming a lot too ) but also I want to know how can I add my new data
structure( if someday i get it, of course =) ) in the postgresql, I mean
where can i find the .h that describes the interface that a spatial access
method, like the R-tree, must have in order to work with postgresql.

I would start by reading the documentation, specifically the part about
"GiST". Once you have understood the concept and code there, go to
reading the rtree code in the backend. That should answer almost all
your questions.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

"jorge alberto" <jorge.is.a.geek@gmail.com> writes:

where can i find the .h that describes the interface that a spatial access
method, like the R-tree, must have in order to work with postgresql.

There is no single .h file that will tell you everything you need to know.
I'd suggest starting here:
http://developer.postgresql.org/pgdocs/postgres/internals.html
with particular attention to chapter 48
http://developer.postgresql.org/pgdocs/postgres/indexam.html
After that the indexam README files might be educational:
src/backend/access/nbtree/README
src/backend/access/gin/README
src/backend/access/gist/README
src/backend/access/hash/README
and then start looking at .h files.

regards, tom lane

We have a question regarding prepared statements. The following code is located in src/backend/tcop/postgres.c:

/* Get the parameter format codes */
numPFormats = pq_getmsgint(input_message, 2);
if (numPFormats > 0)
{
int i;
pformats = (int16 *) palloc(numPFormats * sizeof(int16));
for (i = 0; i < numPFormats; i++)
pformats[i] = pq_getmsgint(input_message, 2);
}

There is similar code for Parameter Lists (ParamListInfo) and Result Format Codes (rformats). Unless we're missing something, a prepared statement would probably never change once prepared.

Would there be any issue or benefit moving the allocation of these buffers to the PreparedStatement structure so they stay with the prepared statement throughout its life? There is probably the question of named versus unnamed prepared statements, but is there anything else that we might be missing?

Along these lines, would it also be possible to keep an Executor State and Expression Context with the statement and just reset key parts of them, rather than rebuilding them from scratch each time a prepared statement is executed?

Thanks

David

"Strong, David" <david.strong@unisys.com> writes:

There is similar code for Parameter Lists (ParamListInfo) and Result Format Codes (rformats). Unless we're missing something, a prepared statement would probably never change once prepared.

I think you're missing something. Or are you just proposing that we
could save one palloc per Bind operation? Trust me, that ain't worth
worrying about. In any case the number of parameters appearing in Bind
could be different from the number appearing in the statement --- the
fact that that's an error doesn't allow you to not process the message
before complaining.

Along these lines, would it also be possible to keep an Executor State and Expression Context with the statement and just reset key parts of them, rather than rebuilding them from scratch each time a prepared statement is executed?

Sounds highly bug-prone to me ... especially in the case where the
preceding execution didn't complete normally ...

regards, tom lane

On Oct 9, 2006, at 7:21 AM, Martijn van Oosterhout wrote:

On Mon, Oct 09, 2006 at 09:15:58AM -0500, jorge alberto wrote:

I want to know how can I add a new spatial access method into the
postgresql
(I'm doing research on spatial access methods( reading a lot of
papers and
programming a lot too ) but also I want to know how can I add my
new data
structure( if someday i get it, of course =) ) in the postgresql,
I mean
where can i find the .h that describes the interface that a
spatial access
method, like the R-tree, must have in order to work with postgresql.

I would start by reading the documentation, specifically the part
about
"GiST". Once you have understood the concept and code there, go to
reading the rtree code in the backend. That should answer almost all
your questions.

Index Access Methods (Ch. 48) for a more general interface may also
be useful, since he implies that R-Tree is not the only spatial
access method he is interested in. While some spatial access
methods, such as R-Tree, are well-suited for a GiST implementation,
it is not a particularly appropriate access method (assumption
mismatch) for some other interesting spatial index types that a
researcher might be interested in implementing.

Cheers,

J. Andrew Rogers (who is also implementing new spatial indexes...)
jrogers@neopolitan.com

Tom,

Thanks for the advice. Yes, we were looking at the possibility of saving the palloc(s) (malloc in some cases) on the statement.

David

________________________________

From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Mon 10/9/2006 9:08 AM
To: Strong, David
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Prepared Statement Question

"Strong, David" <david.strong@unisys.com> writes:

There is similar code for Parameter Lists (ParamListInfo) and Result Format Codes (rformats). Unless we're missing something, a prepared statement would probably never change once prepared.

I think you're missing something. Or are you just proposing that we
could save one palloc per Bind operation? Trust me, that ain't worth
worrying about. In any case the number of parameters appearing in Bind
could be different from the number appearing in the statement --- the
fact that that's an error doesn't allow you to not process the message
before complaining.

Along these lines, would it also be possible to keep an Executor State and Expression Context with the statement and just reset key parts of them, rather than rebuilding them from scratch each time a prepared statement is executed?

Sounds highly bug-prone to me ... especially in the case where the
preceding execution didn't complete normally ...

regards, tom lane

Hi, Jorge,

jorge alberto wrote:

I'm Jorge from Peru South America, and this is my first post

I want to know how can I add a new spatial access method into the
postgresql (I'm doing research on spatial access methods( reading a lot
of papers and programming a lot too ) but also I want to know how can I
add my new data structure( if someday i get it, of course =) ) in the
postgresql, I mean where can i find the .h that describes the interface
that a spatial access method, like the R-tree, must have in order to
work with postgresql.

I think that to understand how postgresql works with spatial access
methods, like the R-tree, I need to find a .h or .c to begin
reading the code, so can you tell me where to start?

Besides the hints others posted here, you might want to look at
contrib/tsearch2 and PostGIS for examples of how to use GIST.

HTH,
Markus

--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org