Re: R-tree, order by, limit

Поиск
Список
Период
Сортировка
От Anton Belyaev
Тема Re: R-tree, order by, limit
Дата
Msg-id d7e834b0809210717s7b3d215dse931356f0f3b56ad@mail.gmail.com
обсуждение исходный текст
Ответ на Re: R-tree, order by, limit  (Volkan YAZICI <yazicivo@ttmail.com>)
Ответы Re: R-tree, order by, limit
Re: R-tree, order by, limit
Список pgsql-general
2008/9/21 Volkan YAZICI <yazicivo@ttmail.com>:
> On Sun, 21 Sep 2008, "Anton Belyaev" <anton.belyaev@gmail.com> writes:
>> SELECT * FROM towns where alt1 <= alt <= alt2 AND long1 <= long <=
>> long2 ORDER BY population LIMIT 10;
>
> You're absolutely on the wrong path. Don't try to implement a logic,
> that has been implemented by PostgreSQL in the most possibly efficient
> way in its bounds. See geographic data types[1] (e.g. box) and
> geographic functions[2] (e.g. @> a.k.a contains).
>
>
> Regards.
>
> [1] http://www.postgresql.org/docs/current/interactive/datatype-geometric.html
> [2] http://www.postgresql.org/docs/current/interactive/functions-geometry.html
>

Volkan,
Thanks you for your reply.
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?
Does population worth including into a (3D) point (In order to create
a 3D R-tree)? Does Postgres perform ODRER/LIMIT efficiently in this
case?

Thanks.
Anton.

В списке pgsql-general по дате отправления:

Предыдущее
От: Volkan YAZICI
Дата:
Сообщение: Re: R-tree, order by, limit
Следующее
От: "Anton Belyaev"
Дата:
Сообщение: Re: R-tree, order by, limit