Re: Testing of various opclasses for ranges

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Testing of various opclasses for ranges
Date: 2012-07-10 22:36:45
Message-ID: CAPpHfdtFWs3R6DiqXwW=3f=DVOxxwZmh92mOihu02DEug6yr5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 10, 2012 at 1:38 PM, Heikki Linnakangas <
heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> I think the ultimate question is, which ones of these should we include in
> core? We cannot drop the existing range_ops opclass, if only because that
> would break pg_upgrade. However, range_ops2 seems superior to it, so I
> think we should make that the default for new indexes.
>

Actually, I'm not fully satisfied with range_ops2. I expect it could be
recommend for all cases, but actually it builds significantly slower and
sometimes requires more pages for search. Likely, we have to write some
recommedation in docs about which opclass to use in particular.
Additionally, somebody could think GiST range indexing becoming tangled.

For SP-GiST, I don't think we need to include both quad and k-d tree
> implementations. They have quite similar characteristics, so IMHO we should
> just pick one. Which one would you prefer? Is there any difference in terms
> of code complexity between them? Looking at the performance test results,
> quad tree seems to be somewhat slower to build, but is faster to query.
> Based on that, I think we should pick the quad tree, query performance
> seems more important.

Agree, I think we should stay at quad tree implemetation.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-07-10 22:39:07 Re: enhanced error fields
Previous Message Joe Conway 2012-07-10 22:28:31 Re: has_language_privilege returns incorrect answer for non-superuser