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.
Show quoted text
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)