| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fractal tree indexing |
| Date: | 2013-02-13 14:43:16 |
| Message-ID: | 511BA684.5080902@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 02/13/2013 09:13 AM, Atri Sharma wrote:
>
> Sent from my iPad
>
> On 13-Feb-2013, at 19:31, Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> .
>> I think its a good idea, the best idea even, but we still have no idea
>> what the requirements are without a clear case for an external index.
>> It could easily turn out that we invent a plausible API that's not
>> actually of use because of requirements for locking. Whoever wants
>> that can do the legwork.
>>
>> IIRC each of the new index types has required some changes to the
>> generic APIs, which makes sense.
>>
>>
> Does that mean we can add support for fractal tree indexes(or some thing on similar lines) in the regular way by changing the generic APIs?
>
> IMO, we could design the fractal tree index and use it as the use case for generic WAL record(I am kind of obsessed with the idea of seeing fractal indexes being supported in Postgres).
>
If they are patented as Alexander says upthread, then surely the idea is
dead in the water.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2013-02-13 14:45:31 | FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] |
| Previous Message | Atri Sharma | 2013-02-13 14:13:20 | Re: Fractal tree indexing |