Re: [HACKERS] static genericcostestimate
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) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] static genericcostestimate
Ramy M. Hassan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] static genericcostestimate
Tom Lane wrote: Ramy M. Hassan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
