Tom Lane wrote:
"Ramy M. Hassan" <[EMAIL PROTECTED]> writes:I am currently working on porting SP-GiST to postgresql.
The genericcostestimate function is currently static. This limits the development of new access methods as loadable modules without touching pgsql sources. Currently I have to include a copy of the function in the module, which is obviously too bad.
Is there any reason to keep this function static ?
Is it really of much use for your access method? It's such a crude hack that I didn't want to encourage people to use it ... it is really just a stopgap until someone gets around to thinking harder about the actual access behavior of the existing index AMs.
BTW, what are you working on? I had no idea that anyone was experimenting with new index methods.
SP-GiST is an adaptation of GiST to support space partitioning trees ( http://www.cs.purdue.edu/homes/aref/dbsystems_files/SP-GiST/ )
The current standalone SP-GiST implementation is based on libgist v1.0 from berkeley ( http://gist.cs.berkeley.edu/libgistv1/ )
The core SP-GiST is being implemented as module to be loaded before any spgist extention module.
I am expecting the first alpha release early of May.
Currently, there is no effort done in cost estimation for SP-GiST, so the genericcostestimate seams to be ok for now.
regards, tom lane
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
