static genericcostestimate

Started by Ramy M. Hassanalmost 21 years ago4 messages
#1Ramy M. Hassan
rhassan@cs.purdue.edu

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ramy M. Hassan (#1)
Re: static genericcostestimate

"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

#3Ramy M. Hassan
rhassan@cs.purdue.edu
In reply to: Tom Lane (#2)
Re: static genericcostestimate

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

#4Alvaro Herrera
alvherre@alvh.no-ip.org
In reply to: Ramy M. Hassan (#3)
Re: 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)