On Fri, Jul 15, 2011 at 1:27 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Ok, committed this now.
>
Thank you.
> I decided to rename the childoffnum field to "downlinkoffnum". I figured
> it'd be dangerous that the field means something subtly different in
> different v
On 13.07.2011 22:04, Heikki Linnakangas wrote:
On 13.07.2011 21:56, Alexander Korotkov wrote:
Thank you very much for detail explanation. But this line of modified
patch
seems strange for me:
*newchildoffnum = blkno;
I believe it should be:
*newchildoffnum = i;
Yes, you're right. It's scary th
On 14.07.2011 13:29, Alexander Korotkov wrote:
On Thu, Jul 14, 2011 at 12:56 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
First, notice that we're setting "ptr->parent = top". 'top' is the current
node we're processing, and ptr represents the node to the right of the
cur
I think there's two bugs in the existing gistFindPath code:
if (top->parent && XLByteLT(top->parent->lsn,
GistPageGetOpaque(page)->nsn) &&
GistPageGetOpaque(page)->rightlink !=
InvalidBlockNumber /* sanity check */ )
{
On Thu, Jul 14, 2011 at 12:56 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> First, notice that we're setting "ptr->parent = top". 'top' is the current
> node we're processing, and ptr represents the node to the right of the
> current node. The current node is *not* the par
On 13.07.2011 21:56, Alexander Korotkov wrote:
Thank you very much for detail explanation. But this line of modified patch
seems strange for me:
*newchildoffnum = blkno;
I believe it should be:
*newchildoffnum = i;
Yes, you're right. It's scary that it worked during testing anyway.
Maybe the r
Thank you very much for detail explanation. But this line of modified patch
seems strange for me:
*newchildoffnum = blkno;
I believe it should be:
*newchildoffnum = i;
--
With best regards,
Alexander Korotkov.
On 30.06.2011 07:50, Jeff Janes wrote:
My concern is that I am unable to prove to myself simply by reading
the code that the 24 line chunk deleted from gistFindPath (near ***
919,947 ) are no longer needed. My familiarity with the gist code
is low enough that it is not surprising that I cann
On 10.07.2011 21:43, Josh Berkus wrote:
Teodor, Oleg, Heikki,
My concern is that I am unable to prove to myself simply by reading
the code that the 24 line chunk deleted from gistFindPath (near ***
919,947 ) are no longer needed. My familiarity with the gist code
is low enough that it is n
Teodor, Oleg, Heikki,
> My concern is that I am unable to prove to myself simply by reading
> the code that the 24 line chunk deleted from gistFindPath (near ***
> 919,947 ) are no longer needed. My familiarity with the gist code
> is low enough that it is not surprising that I cannot prove t
Hi Jeff,
Thank you for review.
On Thu, Jun 30, 2011 at 8:50 AM, Jeff Janes wrote:
> So I tried provoking situations where this surrounding code section
>
would get executed, both patched and unpatched. I have been unable to
> do so--apparently this code is for an incredibly obscure situation
>
On Tue, Jun 28, 2011 at 10:21 AM, Alexander Korotkov
wrote:
> Actually, there is no more direct need of this patch because I've rewrote
> insert function for fast build. But there are still two points for having
> this changes:
> 1) As it was noted before, it simplifies code a bit.
> 2) It would b
Actually, there is no more direct need of this patch because I've rewrote
insert function for fast build. But there are still two points for having
this changes:
1) As it was noted before, it simplifies code a bit.
2) It would be better if childoffnum have the same semantics in regular
insert and f
On 24.05.2011 15:22, Alexander Korotkov wrote:
During preparing patch of my GSoC project I found reasonable to
move childoffnum (GISTInsertStack structure) from parent to child. This
means that now child have childoffnum of parent's link to child. It allows
to maintain entire parts of tree in tha
14 matches
Mail list logo
