2011/5/6 Teodor Sigaev
> As I understood it's because we can't move root to another page.
>>
>
> Actually not. Path to node could change completely, For example, for page
> on second level path is 0-234 (where 0 is a root page, 234 is a page on
> second level). After root split path will be 0-ne
As I understood it's because we can't move root to another page.
Actually not. Path to node could change completely, For example, for page on
second level path is 0-234 (where 0 is a root page, 234 is a page on second
level). After root split path will be 0-new_page-234.
If algorithm could b
2011/5/5 Teodor Sigaev
>
> See several lines above:
>if (parent->blkno == InvalidBlockNumber)
>
>/*
> * end of chain and still didn't found parent, It's
> very-very
> * rare situation when root splited
> */
>
gistFindCorrectParent function have branch with following comment:
/*
* awful!!, we need search tree to find parent ... , but before we
* should release all old parent
*/
Can you provide me an example of case when this branch works?
See several lines above:
if (parent->blkno == Inval
During studying of existing GiST code I have a question.
gistFindCorrectParent function have branch with following comment:
/*
* awful!!, we need search tree to find parent ... , but before we
* should release all old parent
*/
Can you provide me an example of case when this branch works?
On 27.04.2011 09:51, Alexander Korotkov wrote:
On Tue, Apr 26, 2011 at 1:10 PM, Alexander Korotkovwrote:
Since algorithm is focused to reduce I/O, we should expect best
acceleration in the case when index doesn't fitting to memory. Size of
buffers is comparable to size of whole index. It means
On Tue, Apr 26, 2011 at 1:10 PM, Alexander Korotkov wrote:
> Since algorithm is focused to reduce I/O, we should expect best
> acceleration in the case when index doesn't fitting to memory. Size of
> buffers is comparable to size of whole index. It means that if we can hold
> buffers in memory the
On Tue, Apr 26, 2011 at 10:46 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Just palloc() the buffers in memory, at least in the first phase. That'll
> work fine for index creation. Dealing with concurrent searches and inserts
> makes it a lot more complicated, it's better
Congrats on being selected, looking forward to mentor you!
On 25.04.2011 23:09, Alexander Korotkov wrote:
The first question that I would like to discuss is the node buffer storage.
During index build each index page (except leaf) should have several pages
of buffer. So my question is where to s
Hackers!
I was happy to know that my proposal "Fast GiST index build" was accepted to
GSoC 2011! Thank you very much for support! Especially thanks to Heikki
Linnakangas for becoming my mentor!
The first question that I would like to discuss is the node buffer storage.
During index build each ind
10 matches
Mail list logo
