Re: Double sorting split patch

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>

To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

Cc: pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2011-10-06T08:22:19Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix contrib/seg's GiST picksplit method.
- 2a6ebe70fb2f 9.1.0 cited
Some copy editing of pg_read_binary_file() patch.
- 290f1603b420 9.1.0 cited

On Thu, Oct 6, 2011 at 11:06 AM, Heikki Linnakangas <
heikki.linnakangas@enterprisedb.com> wrote:

> On 05.10.2011 15:59, Alexander Korotkov wrote:
>
>> Path without allocating extra bytes is attached.
>> I run some more detailed tests on geonames and two smaller datasets from
>> rtreeportal.org.
>>
>
> Ok, thanks. Looks good to me now, so committed.

Thanks. I'm going to continue work on application of this split method in
following areas:
1) range types
2) seg contrib module
3) cube contrib module (there situation is not so easy, probably some
heuristic of split method selection would be required)
Do you think that separation of some common parts of algorithm implemetation
is resonable in order to avoid code duplication? For example, different
application of algorithm could share function of splits enumeration along
axis which takes pointer to consider_split as an argument.

------
With best regards,
Alexander Korotkov.