Вопрос к гуру Postgres — есть ли принципиальная разница между Linux и
Windows версией (Postgres 8.3.5)? Заранее скажу — Postgres для Windows
нужен для разработки, ибо шибко удобно. Тестирование и продакш будет под
Линуксом.

Проблема заключается в том, что запрос на одной и той же БД под
управлением одной и той же версии Postgres выполняется с разницей во
времени исполнения в 2000 раз (40 секунд против 50 мс)

— имеем БД GeoNames (http://www.geonames.org/), две таблицы,
"все-в-одном" — нормализация отсутствует.
— имеем следующий запрос (выборка всех стран)

select
    gn.geonameid,
    gn.name,
    gn.country,
    an.alternatenameid,
    an.alternatename,
    coalesce(an.alternatename, gn.name) as display    
from (
    select
        gn.geonameid,
        gn.name,
        gn.country,
        (select min(an2.alternatenameid)
            from alternatename an2
            where (an2.geonameid = gn.geonameid)
                and (an2.isolanguage = 'ru')
        ) as alternatenameid
    from geoname gn
    where (gn.fcode = 'PCLI')
) gn
left join alternatename an on (an.alternatenameid = gn.alternatenameid)
order by display asc

В итоге: версия под Linux работает как и должна (50мс), а вот под
Windows планировщик решает перебрать все записи Seq Scan в таблице
alternatename, а там их полтора миллиона (40-60 сек). Я понимаю почему
планировщик иногда включает Seq Scan — когда он решает, что ему нужны
все (или почти все) записи — но почему поведение так отличается от
Linux-версии?

База одна и та же, индексы одни и те же (backup -> restore). Если
добавить ничего незначащее условие

left join alternatename an on ((an.alternatenameid = gn.alternatenameid)
and /* OPT<< */ (an.isolanguage = 'ru') /* >>OPT */)

то Windows-версия работает также замечательно, хотя план все равно
немного другой. Также помогает полное запрещение сканирования

"SET enable_seqscan=false"

но все это меня мало устраивает, мне нужно, чтобы поведение на обоих
платформах хотя бы немного сходилось.

Мне нужно понять чего же мне ожидать дальше — нужно разрабатывать
приложение.

Здравствуйте, mazurkin, Вы писали:


M>Вопрос к гуру Postgres — есть ли принципиальная разница между Linux и
M>Windows версией (Postgres 8.3.5)? Заранее скажу — Postgres для Windows
M>нужен для разработки, ибо шибко удобно. Тестирование и продакш будет под
M>Линуксом.

M>Проблема заключается в том, что запрос на одной и той же БД под
M>управлением одной и той же версии Postgres выполняется с разницей во
M>времени исполнения в 2000 раз (40 секунд против 50 мс)

M>- имеем БД GeoNames (http://www.geonames.org/), две таблицы,
M>"все-в-одном" — нормализация отсутствует.
M>- имеем следующий запрос (выборка всех стран)

M>

M>select
M>    gn.geonameid,
M>    gn.name,
M>    gn.country,
M>    an.alternatenameid,
M>    an.alternatename,
M>    coalesce(an.alternatename, gn.name) as display    
M>from (
M>    select
M>        gn.geonameid,
M>        gn.name,
M>        gn.country,
M>        (select min(an2.alternatenameid)
M>            from alternatename an2
M>            where (an2.geonameid = gn.geonameid)
M>                and (an2.isolanguage = 'ru')
M>        ) as alternatenameid
M>    from geoname gn
M>    where (gn.fcode = 'PCLI')
M>) gn
M>left join alternatename an on (an.alternatenameid = gn.alternatenameid)
M>order by display asc
M>

M>В итоге: версия под Linux работает как и должна (50мс), а вот под
M>Windows планировщик решает перебрать все записи Seq Scan в таблице
M>alternatename, а там их полтора миллиона (40-60 сек). Я понимаю почему
M>планировщик иногда включает Seq Scan — когда он решает, что ему нужны
M>все (или почти все) записи — но почему поведение так отличается от
M>Linux-версии?

M>База одна и та же, индексы одни и те же (backup -> restore). Если
M>добавить ничего незначащее условие

M>

M>left join alternatename an on ((an.alternatenameid = gn.alternatenameid)
M>and /* OPT<< */ (an.isolanguage = 'ru') /* >>OPT */)
M>

M>то Windows-версия работает также замечательно, хотя план все равно
M>немного другой. Также помогает полное запрещение сканирования

M>"SET enable_seqscan=false"

M>но все это меня мало устраивает, мне нужно, чтобы поведение на обоих
M>платформах хотя бы немного сходилось.

M>Мне нужно понять чего же мне ожидать дальше — нужно разрабатывать
M>приложение.

Я не гуру Postres, но попробую ответить.
Могу посоветовать выполнить на обоих базах "VACUUM FULL ANALYZE;".
Также могу посоветовать проверить, все ли настройки баз идентичны.

Smagen wrote:

> Я не гуру Postres, но попробую ответить.
> Могу посоветовать выполнить на обоих базах "VACUUM FULL ANALYZE;".
> Также могу посоветовать проверить, все ли настройки баз идентичны.

Это было сделано первым же делом Но не помогло...

В целом проблема разрешилась изменением системного параметра
"default_statistics_target"

http://www.sql.ru/forum/actualthread.aspx?bid=7&tid=626305&pg=-1

Самое интересно, что оба планировщика работали неправильно. Просто
линуксовый работал неправильно в нужную сторону.