Re: Поиск ближайшего - Mailing list pgsql-ru-general

Добрый день

On Wed, 6 Apr 2005, Oleg Bartunov wrote:

> 1. Система
~$cat /etc/redhat-release
Red Hat Linux release 6.2 (Zoot)

~$cat /proc/cpuinfo
model name      : Pentium II (Klamath)
cpu MHz         : 300.686
bogomips        : 599.65

Планируется в ближайший месяц апгрейд на двухпроцессорный
AMD Opteron(tm) 240. Сейчас думаю имеет ли смысл связываться с PostgreSQL
8.0 или подождать до 8.3

> 2. версия постгреса

7.3.4 (Возможно переход на 8.0)

> 3. структура таблицы (\d tablename)

 Например (одна из двухсот схожих таблиц)
 \d vepp4current_key

                                      Таблица "public.vepp4current_key"
  Колонка   |           Тип            |         Модификаторы
------------+--------------------------+---------------------------------------------------------------------
 inserttime | timestamp with time zone |
 begintime  | timestamp with time zone | not null
 endtime    | timestamp with time zone |
 ver        | integer                  | not null
 rowid      | integer                  | not null default nextval('public.vepp4current_key_rowid_seq'::text)

Индексы: vepp4current_key_time_ver_key ключевое поле btree (begintime, ver),
         vepp4current_key_rowid_key unique btree (rowid)

> 4. запрос + explain analyze

Если я ищу ближайшую валидную запись:

calibrations=# EXPLAIN ANALYZE select begintime from vepp4current_key
where begintime<'yesterday' order by begintime limit 1;

QUERY PLAN

-------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..0.04 rows=1 width=8) (actual time=43.70..43.74 rows=1
loops=1)
   ->  Index Scan using vepp4current_key_time_ver_key on vepp4current_key
(cost=0.00..3329.39 rows=82047 width=8) (actual time=43.69..43.72 rows=2
loops=1)
         Index Cond: (begintime < '2005-04-05 00:00:00+07'::timestamp with
time zone)
 Total runtime: 43.94 msec
                ----------
(записей: 4)

 Если я ищу по строгому равенству

calibrations=# EXPLAIN ANALYZE select begintime from vepp4current_key
where begintime='yesterday' order by begintime limit 1;
                                                                     QUERY
PLAN

----------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..5.26 rows=1 width=8) (actual time=1.14..1.14 rows=0
loops=1)
   ->  Index Scan using vepp4current_key_time_ver_key on vepp4current_key
(cost=0.00..5.26 rows=1 width=8) (actual time=1.13..1.13 rows=0 loops=1)
         Index Cond: (begintime = '2005-04-05 00:00:00+07'::timestamp with
time zone)
 Total runtime: 1.34 msec
                ---------
(записей: 4)


Видно, что отличие в 30 раз (50 мс против 1.3 мс) - хотелось бы это как-то
ликвидировать. Странно, что ничего подобного мне обнаружить не удалось -
вроде поиск по времени вполне распространённая задача.

С уважением
    Евгений


> Думаю, что это доступно и не программисту и уж совсем не требует крови.

P.S. Я только сегодня подписался на список рассылки и не знал об имеющихся
правилах. Текст моего первого сообщения ниже.

>
> On Wed, 6 Apr 2005, Evgeny M. Baldin wrote:
>
> > Добрый день
> >
> > Так уж случилось, что на эксперименте для целей медленного контроля и
> > калибровок стали использовать PostgreSQL. К сожалению средство оказалось
> > не совсем адекватным для нужным нам целей.
> >
> > Преамбула: ключом является время BeginTime. Запросу тоже передаётся
> > время Time. По запросу необходимо выдернуть ближайшую по времени запись,
> > где BeginTime<=Time (назовём эту запись валидной для Time)
> >
> > Амбула: Запрос представляет из себя фразу типа:
> >
> > select * from таблица where BeginTime<=Time
> >                       order by BeginTime desc limit 1;
> >
> > Индексы работают, одиночные запросы проходят более-менее быстро, хотя тоже
> > хотелось бы побыстрее.
> >
> > А вот попытка сопоставить валидные записи для массива времён, особенно
> > когда число записей в таблице превышает десятки тысяч наступает полный :(
> >
> > Что хотелось бы: когда идёт поиск для какого-то числа на предмет
> > равенства, то используется бинарный поиск - это быстро. Хотелось бы иметь
> > поиск подобного рода, но не на предмет поиска точного значения, а на
> > предмет поиска ближайшего. Как я понимаю по числу действий это тоже самое,
> > просто надо помнить предыдущее число.
> >
> > То есть нужен оператор типа равенства - назовём его CLOSE TO для работы с
> > временными данными, стой же самой скоростью работы для быстрого
> > сопоставления.
> >
> > С уважением
> >     Евгений
> >
> > P.S.  Я не программист - я пользователь, поэтому хотелось бы получить
> > результат малой кровью.