Re: Поиск ближайшего

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-1423418003-1112791941=:9870
Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 6 Apr 2005, Evgeny M. Baldin wrote:

> AMD Opteron(tm) 240. Сейчас думаю имеет ли смысл связываться с PostgreSQL
> 8.0 или подождать до 8.3

Ох и долго ждать будешь :) Сейчас выйдет 8.02, beta уже доступна

>
>> 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)
>

а ты vacuum analyze давно делал ? Похоже, что здесь у тебя проблемы.
rows=82047 - это то, что планнер оценивает исходя из pg_stats,
а получает реально - rows=2 ! Ну куда это годится :)
Либо у тебя распределение сильно неправильное, что обычная гисторграмма на
10 бинов недостаточна (тогда надо увеличивать количесвто), либо элементарно
не делал vacuum analyze;
>
>
> Видно, что отличие в 30 раз (50 мс против 1.3 мс) - хотелось бы это как-то
> ликвидировать. Странно, что ничего подобного мне обнаружить не удалось -
> вроде поиск по времени вполне распространённая задача.

Если интересно, какие ключевые слова вы использовали и где ?

как совет на будущее, использовать явный cast

'yesterday'::timestamp with time zone;

планнер, конечно, все понял, но иногда могут быть проблемы

>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---559023410-1423418003-1112791941=:9870--