Re: Fix for seg picksplit function

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix for seg picksplit function
Date: 2010-11-10 15:13:32
Message-ID: 4CDAB69C.2000103@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2010-11-10 14:53, Alexander Korotkov wrote:
>
>
> Actually I can't understand the purpose of FirstOffsetNumber
> and OffsetNumberNext macros. When I wrote the patch I though about
> sortItems as about "clean from all these strange things" array, that's
> why I didn't use OffsetNumberNext there. :)
> I see only way to save logic of these macros is to use array starting
> from FirstOffsetNumber index like in gbt_num_picksplit.
Another reason for not using is FirstOffsetNumber and it's related
macro's on the qsort array, is that InvalidOffsetNumber (0) is not
invalid for the array.
However all other sorts in picksplit functions already seem to do it
this way. I'm not sure it's wise to introduce a different approach.
>
> The assignment to *left and *right at the end of the routine seem
> pretty
> useless (not to mention the comment talking about a routine that
> doesn't
> exist anywhere).
>
> I found, that gtrgm_picksplit in pg_trgm and gtsvector_picksplit in
> core still use this assignment, while gist_box_picksplit
> and gbt_num_picksplit not. If this assignment is overall useless, than
> I think we should remove it from gtrgm_picksplit
> and gtsvector_picksplit in order to not mislead developers of gist
> implementations.
+1

regards,
Yeb Havinga

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-11-10 15:32:48 Re: improved parallel make support
Previous Message Tom Lane 2010-11-10 15:07:12 Re: Fix for seg picksplit function