Just to clarify situation a bit. I noticed buffer tree technique while
reseaching
sp-gist and got an idea to use it for improving CREATE INDEX for GiST, which
is what we were looking many times. Alexander is working on his thesis and
this project suits ideally for him and community. Since I and
On Mon, Apr 4, 2011 at 8:50 PM, Robert Haas wrote:
> OK. Could you briefly describe the algorithm you propose to
> implement, bearing in mind that I haven't read the paper?
>
The technique can be very briefly described in following rules.
M = number of index keys fitting in RAM;
B = number of i
On Mon, Apr 4, 2011 at 12:46 PM, Alexander Korotkov
wrote:
> On Mon, Apr 4, 2011 at 7:04 PM, Robert Haas wrote:
>>
>> On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov
>> wrote:
>> > Project name
>> > Fast GiST index build
>>
>> Would/could/should this be implemented in a manner similar to the
On Mon, Apr 4, 2011 at 7:04 PM, Robert Haas wrote:
> On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov
> wrote:
> > Project name
> > Fast GiST index build
>
> Would/could/should this be implemented in a manner similar to the
> existing "GIN fast update" feature?
>
I've mentioned this problem i
Robert Haas writes:
> On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov
> wrote:
>> Project name
>> Fast GiST index build
> Would/could/should this be implemented in a manner similar to the
> existing "GIN fast update" feature?
Fast build and fast update tend to be two different problems ...
On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov wrote:
> Project name
> Fast GiST index build
Would/could/should this be implemented in a manner similar to the
existing "GIN fast update" feature?
It's occurred to me to wonder whether even btree indexes would benefit
from this type of optimiza
