Re: R-tree, order by, limit

From: "Anton Belyaev" <anton(dot)belyaev(at)gmail(dot)com>
To: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Anton Belyaev" <anton(dot)belyaev(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: R-tree, order by, limit
Date: 2008-09-22 10:14:28
Message-ID: d7e834b0809220314s44ac76a1v6cdaa62727009e03@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2008/9/21 Martijn van Oosterhout <kleptog(at)svana(dot)org>:
> On Sun, Sep 21, 2008 at 06:17:39PM +0400, Anton Belyaev wrote:
>> Geometry types and functions use R-tree indexes anyways.
>>
>> I can rephrase the query using geometry language of Postgres:
>> SELECT * FROM towns WHERE towns.coordinates <@ box(alt1, long1, alt2,
>> long2) ORDER BY population LIMIT 10;
>>
>> And the questions about population remain the same:
>> How to avoid examination of all the towns in the rectangle knowing
>> that we need only 10 biggest?
>
> I don't know if it solves your problem, but you should be able to do a
> multi-column GiST index with both the position data and the population
> data in it. However, I'm unsure if postgresql will correctly use the
> index to solve the order by...

Martijn, thanks for you reply.
Implementing a 3D R-tree index in Postgres is only possible via
implementation of GiST interface. At least, this is the only approach
I consider, because implementing a brand new index access method
requires much more than just classic R-tree implementation.
So, yes, question remains the same, but a bit updated:
How efficiently Postgres handles ORDER BY + LIMIT when using GiST?
(Particularly, when an R-tree is implemented via GiST).

Anton.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Anton Belyaev 2008-09-22 10:18:08 Re: R-tree, order by, limit
Previous Message Bohdan Linda 2008-09-22 08:37:57 Re: Getting cozy with weekly PITR