Re: Поиск ближайшего
От | Oleg Bartunov |
---|---|
Тема | Re: Поиск ближайшего |
Дата | |
Msg-id | Pine.GSO.4.62.0504061657380.9870@ra.sai.msu.su обсуждение исходный текст |
Ответ на | Re: Поиск ближайшего (Oleg Bartunov <oleg@sai.msu.su>) |
Ответы |
Re: Поиск ближ
Re: Поиск ближайшего |
Список | pgsql-ru-general |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1691952160-1112792767=:9870 Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 6 Apr 2005, Oleg Bartunov wrote: > On Wed, 6 Apr 2005, Evgeny M. Baldin wrote: > >> >> calibrations=# EXPLAIN ANALYZE select begintime from vepp4current_key >> where begintime<'yesterday' order by begintime limit 1; >> кстати, а сколько всего записей без ' limit 1' ? Если там много, то чудес нет, сортировать десятки тысяч записей требуется время. Поэтому тебе надо использовать range, т.е. задать разумный нижний предел и не париться. Это дело приложения и серого вещества разработчиков приложения. Другое дело, и мы пару раз этот вопрос поднимали, что limit на самом деле является синтаксической затычкой, т.е. все вытаскивается, сортируется согласно order by, а потом тупо и грязно вытаскиваются необходимые данные. На самом деле, все можно делать по уму, т.е. использовать partial sort, например, в твоей задаче надо вытащить только 1 строчку, а про все остальные тебе совсем не важно, поэтому и сортировку можно остановить. Есть и еще алгоритмы. А ключевым словом, к твоей задаче является 'top-k query' и на этк тему написаноо куча работ. Мы с Федей Сигаевым года три назад даже патч сделали, но тогда его не приняли из-за его плохой реализации. > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---559023410-1691952160-1112792767=:9870--
В списке pgsql-ru-general по дате отправления: