Thread: static genericcostestimate

From:
"Ramy M. Hassan"
Date:

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



From:
Tom Lane
Date:

"Ramy M. Hassan" <> 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


From:
"Ramy M. Hassan"
Date:

Tom Lane wrote:

>"Ramy M. Hassan" <> 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
>  
>



From:
Alvaro Herrera
Date:

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)