Thread: static genericcostestimate
Hi, 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 ? Thanks
"Ramy M. Hassan" <rhassan@cs.purdue.edu> writes: > 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. regards, tom lane
Tom Lane wrote: >"Ramy M. Hassan" <rhassan@cs.purdue.edu> writes: > > >>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. > > > I am currently working on porting SP-GiST to postgresql. 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 > >
On Sun, Apr 10, 2005 at 07:51:23PM +0200, Ramy M. Hassan wrote: Hey Ramy, > I am currently working on porting SP-GiST to postgresql. > 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. What happened to this project? Is it still alive? Did you release anything? -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) "Et put se mouve" (Galileo Galilei)