Re: static genericcostestimate

From: Ramy M. Hassan
Subject: Re: static genericcostestimate
Date: ,
(view: Whole thread, Raw)
In response to: Re: static genericcostestimate  (Tom Lane)
Responses: Re: static genericcostestimate  (Alvaro Herrera <>)
List: pgsql-hackers

Tree view

static genericcostestimate  ("Ramy M. Hassan", )
 Re: static genericcostestimate  (Tom Lane, )
  Re: static genericcostestimate  ("Ramy M. Hassan", )
   Re: static genericcostestimate  (Alvaro Herrera <>, )

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 ( )
The current standalone SP-GiST implementation is based on libgist v1.0 
from berkeley ( )
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

pgsql-hackers by date:

From: Oliver Jowett
Subject: Re: Unicode problems on IRC
From: Josh Berkus
Subject: Re: [PERFORM] Functionscan estimates