From: | "Ramy M(dot) Hassan" <rhassan(at)cs(dot)purdue(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: static genericcostestimate |
Date: | 2005-04-10 17:51:23 |
Message-ID: | 4259679B.8070209@cs.purdue.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>"Ramy M. Hassan" <rhassan(at)cs(dot)purdue(dot)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.
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew - Supernews | 2005-04-10 18:17:59 | Re: Unicode problems on IRC |
Previous Message | Marc G. Fournier | 2005-04-10 17:48:12 | Re: Three-byte Unicode characters |