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

Добрый день

On Wed, 6 Apr 2005, Oleg Bartunov wrote:

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

Что за гистограммы и что надо с ними делать?

vacuum analyze делается раз в сутки вместе с бэкапом

строчка в crontab:

00 3 * * * vacuumdb -a -z  ; /volume/3/var_lib_pgsql/bin/dumpdb.pl

Делать vacuum analyze чаще чем раз в сутки не реально - машина слабая, а
база используется довольно активно. Не сменили её по причине
исключительной стабильности конкретной машины (последняя пара попыток
закончилась крахом - так что теперь на воду дуем).

Я попробовал сделать VACUUM ANALYZE руками, но не сработало. Повторный
запуск прошёл быстрее, но это потому что всё в кэш закачалось, так как
после обращения к другим таблицам при обращении к исследуемой результаты
остались те, что я привёл.

А, кажется нашёл: тест на равенство я делал сразу после неравенства, то
есть данные уже были в кэше, ежели обратиться к той таблице, к которой не
обращался, то вообще ужас получается

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

------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..5.80 rows=1 width=8) (actual time=525.04..525.04
rows=0 loops=1)
   ->  Index Scan using kelktemp_key_time_ver_key on kelktemp_key
(cost=0.00..5.80 rows=1 width=8) (actual time=525.02..525.02 rows=0
loops=1)
         Index Cond: (begintime = '2005-04-05 00:00:00+07'::timestamp with
time zone)
 Total runtime: 525.30 msec
                -----
(записей: 4)

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

по сайту PostgreSQL, слова сейчас даже и не вспомню - что-то вроде time
interval. Изначально идея была основываться на временных интервалах - то
есть каждая запись имеет BeginTime и EndTime - но проблемы с поиском
перекрытий, а так же отсутствие реальной необходимости трансформировали
всё к ключу по одному времени.

> как совет на будущее, использовать явный cast
>
>   'yesterday'::timestamp with time zone;
>
> планнер, конечно, все понял, но иногда могут быть проблемы

В программе так и делаю, а прилагаемый select был просто набран для
примера, поэтому явного каста писать не стал. Кстати, замечено, что если
указать просто timestamp без timezone, то наступают вилы - видимо, это
чем-то объясняется, хотя странно - и там и сям время.

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

P.S. Странно, что max и min сканируют всю таблицу как любые агрегатные
функции - причина понятна, но конкретно эти функции можно было вполне
сделать и поинтеллектуальнее. Я так понял, что не я один на эти грабли
наступил.

P.P.S. На сколько 8 с копейками стабильно по сравнению с 7.3.4 например
для тех же задач?