|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Evgenij M. Baldin 2:5020/400 22 Mar 2002 13:35:38
To : Eugene Kornyakov
Subject : Re: Postgres тюнинг - результаты
--------------------------------------------------------------------------------
Добрый день
Eugene Kornyakov <ev@asdc.kz> wrote:
> т е если
> enable_seqscan = true
> то использование индексов на запросах средней сложности, а особенно
> order by
> зависит от погоды и атмосферного давления
> причем что на версии 7.2 или 7.1
> а если индексы не исп то понятно, что имеем тормоза
Гхмм - я так понял, что postgres решает как ему до чего-то доступаться на
основе статистики, собранной vacuum analyze. То есть, если регулярно это
запускать, то все O'k - выбирается наиболее быстрый способ. Если это не
так, то это бага - запросить авторов.
> ну я еще добавил shared memory для постгреса
> и sort memory
> а также каждую ночь делается
> vacuum full
> и перестройка индекса
каждую ночь бэкап через pg_dump - студент скрипт для этого специальный
написал - удобно, когда они есть - студенты то есть :)
А где shared memory раздаётся? shared_buffers?
А сколько, конретно, у тебя отведено под sort_mem? А то мне грозят деястки
миллионов записей :( - правда, пока в отдалённом будущем :)
> ==================================================
> Может у кого есть еще идеи и опыт наступания на грабли ???
Попытка сделать вместо
max_connections = 32 # 1-1024
что-то вроде
max_connections = 64 # 1-1024
приводит к невозможности перезапустить сервер - 7.1 - шо це таке?
Когда в запросах присутствует order by (вроде с этим связано) - скорость
запроса упирается в cpu - это как?
С уважением
Евгений
--
Budker Institute of Nuclear Physics
e-mail: E.M.Baldin@inp.nsk.su
WWW: http://www.inp.nsk.su/~baldin
--- ifmail v.2.15dev5
* Origin: BINP, Novosibirsk, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
