From: | "Evgeny M(dot) Baldin" <E(dot)M(dot)Baldin(at)inp(dot)nsk(dot)su> |
---|---|
To: | pgsql-ru-general(at)postgresql(dot)org |
Subject: | Re: Поиск ближайшего |
Date: | 2005-04-06 13:44:31 |
Message-ID: | Pine.LNX.4.58.0504062006120.31034@star.inp.nsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 например
для тех же задач?
From | Date | Subject | |
---|---|---|---|
Next Message | Evgeny M. Baldin | 2005-04-06 13:49:13 | Re: Поиск ближайшего |
Previous Message | Teodor Sigaev | 2005-04-06 13:26:12 | Re: Поиск ближ |