ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Linux vs. Windows
25 сообщений из 26, страница 1 из 2
  1  все
Linux vs. Windows
    #35733527
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Вопрос к гуру Postgres - есть ли принципиальная разница между Linux и Windows версией (Postgres 8.3.5)? Заранее скажу - персональный Postgres для Windows нужен для разработки, так как это удобно. Тестирование и продакш будет под Линуксом конечно.

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
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-версии? Версия под Linux настройке почти не подвергалась, товарищ только размеры shared_buffers и temp_buffers увеличил, правда железо там помощнее, но зато там же еще Oracle под разработку крутится.

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

Код: plaintext
1.
left join alternatename an on ((an.alternatenameid = gn.alternatenameid) and /* OPT<< */ (an.isolanguage = 'ru') /* >>OPT */)

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

"SET enable_seqscan=false"

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

Хочу понять как мне действовать дальше. Порулил немного параметрами postgresql.conf - пока результатов нет. Я понимаю, что Windows - не продакшн платформа для Postgres. Я бы смирился с потерей производительности в 10 раз - но тут прямо фейсом об тейбл сразу. Не припомню чтобы Firebird или Oracle так себя вели под Windows.

Просто скажите, кто работал с Postgres под обеими платформами - они ведут себя идентично, особенностей нет? Если нет, буду дальше крутить.
...
Рейтинг: 0 / 0
24.12.2008, 20:07
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733542
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Nick Mazurkin пишет:

> Вопрос к гуру Postgres - есть ли принципиальная разница между Linux и
> Windows версией (Postgres 8.3.5)? Заранее скажу - персональный Postgres

Большой принципиальной разницы нет. Один сервак просто у тебя настроен,
другой - нет. скорее всего.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
24.12.2008, 20:21
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733559
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Я бы сказал, что они оба не настроены. Наверное Лайнуксу просто повезло немного больше :) Буду крутить дальше, спасибо.

На всякий случай приведу планы.

"Хороший" запрос на сервере под Лайнуксом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Sort  (cost= 127 . 74 .. 127 . 75  rows= 1  width= 41 ) (actual time= 15 . 727 .. 15 . 921  rows= 191  loops= 1 )
  Sort Key: (COALESCE(an.alternatename, gn.name))
  Sort Method:  quicksort  Memory: 52kB
  ->  Nested Loop Left Join  (cost= 55 . 36 .. 127 . 73  rows= 1  width= 41 ) (actual time= 0 . 142 .. 14 . 944  rows= 191  loops= 1 )
        ->  Index Scan using idx_geoname_fcode on geoname gn  (cost= 0 . 00 .. 8 . 57  rows= 1  width= 18 ) (actual time= 0 . 032 .. 0 . 421  rows= 191  loops= 1 )
              Index Cond: ((fcode)::text = 'PCLI'::text)
        ->  Index Scan using pk_alternatenameid on alternatename an  (cost= 55 . 36 .. 63 . 79  rows= 1  width= 23 ) (actual time= 0 . 005 .. 0 . 006  rows= 1  loops= 191 )
              Index Cond: (an.alternatenameid = (subplan))
              SubPlan
                ->  Aggregate  (cost= 55 . 35 .. 55 . 36  rows= 1  width= 4 ) (actual time= 0 . 062 .. 0 . 063  rows= 1  loops= 191 )
                      ->  Bitmap Heap Scan on alternatename an2  (cost= 4 . 51 .. 55 . 35  rows= 1  width= 4 ) (actual time= 0 . 039 .. 0 . 057  rows= 1  loops= 191 )
                            Recheck Cond: (geonameid = $ 0 )
                            Filter: ((isolanguage)::text = 'ru'::text)
                            ->  Bitmap Index Scan on idx_alternatename_geonameid  (cost= 0 . 00 .. 4 . 51  rows= 13  width= 0 ) (actual time= 0 . 018 .. 0 . 018  rows= 116  loops= 191 )
                                  Index Cond: (geonameid = $ 0 )
                ->  Aggregate  (cost= 55 . 35 .. 55 . 36  rows= 1  width= 4 ) (actual time= 0 . 062 .. 0 . 063  rows= 1  loops= 191 )
                      ->  Bitmap Heap Scan on alternatename an2  (cost= 4 . 51 .. 55 . 35  rows= 1  width= 4 ) (actual time= 0 . 039 .. 0 . 057  rows= 1  loops= 191 )
                            Recheck Cond: (geonameid = $ 0 )
                            Filter: ((isolanguage)::text = 'ru'::text)
                            ->  Bitmap Index Scan on idx_alternatename_geonameid  (cost= 0 . 00 .. 4 . 51  rows= 13  width= 0 ) (actual time= 0 . 018 .. 0 . 018  rows= 116  loops= 191 )
                                  Index Cond: (geonameid = $ 0 )
Total runtime:  16 . 188  ms

"Плохой" запрос на сервере под Windows:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
QUERY PLAN
Sort  (cost= 1430901 . 25 .. 1430968 . 55  rows= 26919  width= 41 ) (actual time= 48994 . 296 .. 48994 . 366  rows= 191  loops= 1 )
  Sort Key: (COALESCE(an.alternatename, gn.name))
  Sort Method:  quicksort  Memory: 42kB
  ->  Hash Left Join  (cost= 52071 . 71 .. 1428091 . 01  rows= 26919  width= 41 ) (actual time= 47194 . 326 .. 48990 . 600  rows= 191  loops= 1 )
        Hash Cond: ((subplan) = an.alternatenameid)
        ->  Index Scan using idx_geoname_fcode on geoname gn  (cost= 0 . 00 .. 32028 . 69  rows= 26919  width= 18 ) (actual time= 0 . 046 .. 0 . 796  rows= 191  loops= 1 )
              Index Cond: ((fcode)::text = 'PCLI'::text)
        ->  Hash  (cost= 25344 . 65 .. 25344 . 65  rows= 1455765  width= 23 ) (actual time= 46810 . 781 .. 46810 . 781  rows= 1455765  loops= 1 )
              ->  Seq Scan on alternatename an  (cost= 0 . 00 .. 25344 . 65  rows= 1455765  width= 23 ) (actual time= 0 . 035 .. 952 . 199  rows= 1455765  loops= 1 )
        SubPlan
          ->  Aggregate  (cost= 33 . 04 .. 33 . 05  rows= 1  width= 4 ) (actual time= 0 . 082 .. 0 . 083  rows= 1  loops= 382 )
                ->  Index Scan using idx_alternatename_geonameid on alternatename an2  (cost= 0 . 00 .. 33 . 04  rows= 1  width= 4 ) (actual time= 0 . 055 .. 0 . 077  rows= 1  loops= 382 )
                      Index Cond: (geonameid = $ 0 )
                      Filter: ((isolanguage)::text = 'ru'::text)
Total runtime:  48994 . 729  ms

Запрос под Windows с дополнительным условием (см. первый пост):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
QUERY PLAN
Sort  (cost= 1385790 . 42 .. 1385857 . 72  rows= 26919  width= 41 ) (actual time= 358 . 688 .. 358 . 755  rows= 191  loops= 1 )
  Sort Key: (COALESCE(an.alternatename, gn.name))
  Sort Method:  quicksort  Memory: 42kB
  ->  Hash Left Join  (cost= 15219 . 56 .. 1382980 . 17  rows= 26919  width= 41 ) (actual time= 243 . 791 .. 356 . 965  rows= 191  loops= 1 )
        Hash Cond: ((subplan) = an.alternatenameid)
        ->  Index Scan using idx_geoname_fcode on geoname gn  (cost= 0 . 00 .. 32028 . 69  rows= 26919  width= 18 ) (actual time= 0 . 045 .. 1 . 310  rows= 191  loops= 1 )
              Index Cond: ((fcode)::text = 'PCLI'::text)
        ->  Hash  (cost= 13579 . 47 .. 13579 . 47  rows= 89287  width= 23 ) (actual time= 243 . 517 .. 243 . 517  rows= 81561  loops= 1 )
              ->  Bitmap Heap Scan on alternatename an  (cost= 1676 . 38 .. 13579 . 47  rows= 89287  width= 23 ) (actual time= 19 . 121 .. 135 . 614  rows= 81561  loops= 1 )
                    Recheck Cond: ((isolanguage)::text = 'ru'::text)
                    ->  Bitmap Index Scan on idx_alternatename_isolanguage  (cost= 0 . 00 .. 1654 . 06  rows= 89287  width= 0 ) (actual time= 17 . 935 .. 17 . 935  rows= 81561  loops= 1 )
                          Index Cond: ((isolanguage)::text = 'ru'::text)
        SubPlan
          ->  Aggregate  (cost= 33 . 04 .. 33 . 05  rows= 1  width= 4 ) (actual time= 0 . 072 .. 0 . 072  rows= 1  loops= 382 )
                ->  Index Scan using idx_alternatename_geonameid on alternatename an2  (cost= 0 . 00 .. 33 . 04  rows= 1  width= 4 ) (actual time= 0 . 048 .. 0 . 068  rows= 1  loops= 382 )
                      Index Cond: (geonameid = $ 0 )
                      Filter: ((isolanguage)::text = 'ru'::text)
Total runtime:  358 . 962  ms

Я пока только учусь и не силен, но то, что стоимость реального запроса отличается от предполагаемой стоимости - говорит ли о том, что планировщик не совсем понимает, что делает? (Про меня - не вопрос - я пока точно не понимаю :) )
...
Рейтинг: 0 / 0
24.12.2008, 20:45
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733582
Гость_0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость_0
Гость
после restore необходимо делать analyze чтобы собрать статистику распределения данных, необходимую планировщику для правильного планирования
...
Рейтинг: 0 / 0
24.12.2008, 21:03
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733614
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
К сожалению ни VACUUM FULL ANALYSE ни просто ANALYSE на ситуацию не влияют
...
Рейтинг: 0 / 0
24.12.2008, 21:34
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733631
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
Nick Mazurkin,

мне кажется надо начать со сравнения настроек планировщика, что-то вроде
Код: plaintext
1.
2.
3.
4.
5.
6.
select n, current_setting(n) from (values
      ('seq_page_cost'),
      ('random_page_cost'),
      ('cpu_tuple_cost'),
      ('cpu_index_tuple_cost'),
      ('cpu_operator_cost')
) as s(n);
...
Рейтинг: 0 / 0
24.12.2008, 21:48
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733652
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Проверил - одинаково. Вообще оба сервера "из коробки". На линуксовом только увеличены shared_buffers и temp_buffers. Попытки увеличить эти же буферы на Windows на результат не влияют.
...
Рейтинг: 0 / 0
24.12.2008, 22:11
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733900
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sherzod_
Участник
авторЗаранее скажу - персональный Postgres для Windows нужен для разработки, так как это удобно.
простите за офтоп-чем?
...
Рейтинг: 0 / 0
25.12.2008, 06:51
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35733978
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Я сижу на работе под Windows - а иметь персональный сервер для разработки рекомендуется всеми советчиками по правильным методологиям. Кроме того я работаю и дома, а там вообще только одна машина (под Windows). Переезд под Linux - не вариант.

Кроме того в данный момент мне просто интересно, почему планировщик Postgres под Windows из всех вариантов выбирает самый чудовищный и где я ему помог в этом :)
...
Рейтинг: 0 / 0
25.12.2008, 08:58
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734156
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
Nick MazurkinКроме того я работаю и дома, а там вообще только одна машина (под Windows).

Поставьте на Windows VMWare, а на него - тот же самый Linux, что Production. Я в свое время долго не мог поверить в то, что такая комбинация даст какую-то пользу, кроме сексуального удовлетворения, но оказывается это достаточно стабильно и быстро, по крайней мере на 2.8GHz 2GB RAM. Очень рекомендую.

Nick MazurkinКроме того в данный момент мне просто интересно, почему планировщик Postgres под Windows из всех вариантов выбирает самый чудовищный и где я ему помог в этом :)

Тут под одним и тем же сервером на Linux порой всю плешь исскоблишь, почему он этакие планы откаблучивает, а Вы под Windows. Не плодите себе проблем. Они постоянно, в каждом релизе в планировщике чего-то подкручивают, вот и разница.
...
Рейтинг: 0 / 0
25.12.2008, 10:12
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734187
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ёш
Участник
Nick MazurkinПроверил - одинаково. Вообще оба сервера "из коробки". На линуксовом только увеличены shared_buffers и temp_buffers. Попытки увеличить эти же буферы на Windows на результат не влияют.точно одинаковые postgresql.conf ? сравните их diff'ом. посмотрите, одинаковый ли effective_cache_size.
...
Рейтинг: 0 / 0
25.12.2008, 10:23
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734385
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Nick Mazurkin"Хороший" запрос на сервере под Лайнуксом:

Код: plaintext
1.
        ->  Index Scan using idx_geoname_fcode on geoname gn  (rows= 1 ) (actual rows= 191 )
              Index Cond: ((fcode)::text = 'PCLI'::text)

"Плохой" запрос на сервере под Windows:

Код: plaintext
1.
        ->  Index Scan using idx_geoname_fcode on geoname gn  (rows= 26919 ) (actual rows= 191 )
              Index Cond: ((fcode)::text = 'PCLI'::text)
на линуксе планировщик ошибается в оценке кол-ва строк на два порядка в меньшую сторону, на виндах - на три порядка в большую. это серьезные ошибки. соберите самую подробную статистику по таблицам, потом покажите explain analyze.

set default_statistics_target to 1000;
analyze geoname;
analyze alternatename;
explain analyze select ...
...
Рейтинг: 0 / 0
25.12.2008, 11:34
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734431
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Cane Cat FisherПоставьте на Windows VMWare, а на него - тот же самый Linux, что Production. Я в свое время долго не мог поверить в то, что такая комбинация даст какую-то пользу, кроме сексуального удовлетворения, но оказывается это достаточно стабильно и быстро, по крайней мере на 2.8GHz 2GB RAM. Очень рекомендую.

Да, собственно к этому варианту и склоняюсь сейчас, просто ситуация застала меня в расплох - до этого работал только с Firebird, MySQL, Oracle - да и уже любопытно на самом деле.

С виртуальными машинами действительно удобно, правда вот Oracle@CentOs5 у меня нещадно тормозил под VMWare, но Postgres более поджарый, да и рабочий комп буду апгрейдить.
...
Рейтинг: 0 / 0
25.12.2008, 11:45
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734493
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Ёшсравните их diff'ом. посмотрите, одинаковый ли effective_cache_size.

В данный момент под Windows и под CenOs в дефолтных конфигах изменены только shared_buffers (256MB) и temp_buffers (128MB) - одинаково.

Параметр effective_cache_size не задан. Вернее сказать я устанавливал effective_cache_size в 1/4..1/2 оперативки (2GB) под Windows и перезапускал сервис сервера - без эффекта. Сейчас закомментировал обратно.
...
Рейтинг: 0 / 0
25.12.2008, 12:03
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734504
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
LeXa NalBat[quot Nick Mazurkin]
на линуксе планировщик ошибается в оценке кол-ва строк на два порядка в меньшую сторону, на виндах - на три порядка в большую. это серьезные ошибки. соберите самую подробную статистику по таблицам, потом покажите explain analyze.

set default_statistics_target to 1000;


Вы вероятно провидец?! Ваш волшебный параметр заставил сервер под Windows работать идентично - план получился такой же и время работы идентично! Ушел читать доки.

Но если вам не трудно будет - опишите в двух строчках что произошло?
...
Рейтинг: 0 / 0
25.12.2008, 12:07
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734517
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
P.S. Как я и говорил - конфиги на обоих платформах почти не трогались, этот параметр был закомментирован и там и там. Поставил значение в 1000 - буду надеяться, что больше фокусов не будет - а то придется из разработчика переквалифицировать в администратора БД :)
...
Рейтинг: 0 / 0
25.12.2008, 12:11
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734526
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Nick Mazurkinплан получился такой же и время работы идентично

Но если вам не трудно будет - опишите в двух строчках что произошло?план все-таки покажите пожалуйста. в двух словах - на выбор плана влияет в частности статистика распределения значений в полях таблиц. так как планировщик ошибся в оценке кол-ва строк удовлетворяющих условию fcode='PCLI', то сбор подробной статистики может помочь.
...
Рейтинг: 0 / 0
25.12.2008, 12:12
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734534
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
LeXa NalBatэто серьезные ошибки. соберите самую подробную статистику по таблицам, потом покажите explain analyze.

А, да. Вдруг вам любопытно - вот план выполнения под Windows - практически полностью идентичен Линуксовому только на 30% медленнее. Но там и серверная машина гораздо мощнее чем мой рабочий компьютер.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
QUERY PLAN
Sort  (cost= 17595 . 86 .. 17596 . 93  rows= 431  width= 41 ) (actual time= 21 . 623 .. 21 . 699  rows= 191  loops= 1 )
  Sort Key: (COALESCE(an.alternatename, gn.name))
  Sort Method:  quicksort  Memory: 42kB
  ->  Nested Loop Left Join  (cost= 15 . 58 .. 17577 . 00  rows= 431  width= 41 ) (actual time= 0 . 171 .. 19 . 670  rows= 191  loops= 1 )
        ->  Index Scan using idx_geoname_fcode on geoname gn  (cost= 0 . 00 .. 631 . 45  rows= 431  width= 18 ) (actual time= 0 . 044 .. 0 . 429  rows= 191  loops= 1 )
              Index Cond: ((fcode)::text = 'PCLI'::text)
        ->  Index Scan using pk_alternatenameid on alternatename an  (cost= 15 . 58 .. 23 . 73  rows= 1  width= 23 ) (actual time= 0 . 008 .. 0 . 009  rows= 1  loops= 191 )
              Index Cond: (an.alternatenameid = (subplan))
              SubPlan
                ->  Aggregate  (cost= 15 . 57 .. 15 . 58  rows= 1  width= 4 ) (actual time= 0 . 083 .. 0 . 083  rows= 1  loops= 191 )
                      ->  Index Scan using fki_geoname_id on alternatename an2  (cost= 0 . 00 .. 15 . 56  rows= 1  width= 4 ) (actual time= 0 . 054 .. 0 . 078  rows= 1  loops= 191 )
                            Index Cond: (geonameid = $ 0 )
                            Filter: ((isolanguage)::text = 'ru'::text)
                ->  Aggregate  (cost= 15 . 57 .. 15 . 58  rows= 1  width= 4 ) (actual time= 0 . 083 .. 0 . 083  rows= 1  loops= 191 )
                      ->  Index Scan using fki_geoname_id on alternatename an2  (cost= 0 . 00 .. 15 . 56  rows= 1  width= 4 ) (actual time= 0 . 054 .. 0 . 078  rows= 1  loops= 191 )
                            Index Cond: (geonameid = $ 0 )
                            Filter: ((isolanguage)::text = 'ru'::text)
Total runtime:  21 . 923  ms
...
Рейтинг: 0 / 0
25.12.2008, 12:16
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734547
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
P.S. И насколько я понимаю из вашего замечания, планировщик под Windows теперь ошибается всего в три раза в большую сторону - уже без "порядков"?
...
Рейтинг: 0 / 0
25.12.2008, 12:22
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734550
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Nick MazurkinА, да. Вдруг вам любопытно - вот план выполнения под Windows

Код: plaintext
1.
        ->  Index Scan using idx_geoname_fcode on geoname gn  (rows= 431 ) (actual rows= 191 )
              Index Cond: ((fcode)::text = 'PCLI'::text)
интересно, исправилась ли ошибка с оценкой кол-ва строк. все ок, имхо, приемлемая ошибка в два раза, 431 ~= 191.
...
Рейтинг: 0 / 0
25.12.2008, 12:24
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734663
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Ради науки поставили под Линуксом default_statistics_target=1000, план скорректировался к аналогичному

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Sort  (cost= 16617 . 93 .. 16618 . 91  rows= 390  width= 41 ) (actual time= 14 . 032 .. 14 . 227  rows= 191  loops= 1 )
  Sort Key: (COALESCE(an.alternatename, gn.name))
  Sort Method:  quicksort  Memory: 52kB
  ->  Nested Loop Left Join  (cost= 16 . 44 .. 16601 . 15  rows= 390  width= 41 ) (actual time= 0 . 095 .. 13 . 341  rows= 191  loops= 1 )
        ->  Index Scan using idx_geoname_fcode on geoname gn  (cost= 0 . 00 .. 581 . 56  rows= 390  width= 18 ) (actual time= 0 . 026 .. 0 . 415  rows= 191  loops= 1 )
              Index Cond: ((fcode)::text = 'PCLI'::text)
        ->  Index Scan using pk_alternatenameid on alternatename an  (cost= 16 . 44 .. 24 . 62  rows= 1  width= 23 ) (actual time= 0 . 004 .. 0 . 006  rows= 1  loops= 191 )
              Index Cond: (an.alternatenameid = (subplan))
              SubPlan
                ->  Aggregate  (cost= 16 . 43 .. 16 . 44  rows= 1  width= 4 ) (actual time= 0 . 054 .. 0 . 055  rows= 1  loops= 191 )
                      ->  Index Scan using idx_alternatename_geonameid on alternatename an2  (cost= 0 . 00 .. 16 . 43  rows= 1  width= 4 ) (actual time= 0 . 030 .. 0 . 050  rows= 1  loops= 191 )
                            Index Cond: (geonameid = $ 0 )
                            Filter: ((isolanguage)::text = 'ru'::text)
                ->  Aggregate  (cost= 16 . 43 .. 16 . 44  rows= 1  width= 4 ) (actual time= 0 . 054 .. 0 . 055  rows= 1  loops= 191 )
                      ->  Index Scan using idx_alternatename_geonameid on alternatename an2  (cost= 0 . 00 .. 16 . 43  rows= 1  width= 4 ) (actual time= 0 . 030 .. 0 . 050  rows= 1  loops= 191 )
                            Index Cond: (geonameid = $ 0 )
                            Filter: ((isolanguage)::text = 'ru'::text)
Total runtime:  14 . 465  ms
...
Рейтинг: 0 / 0
25.12.2008, 13:01
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35734719
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Уменьшил параметр до сотни - все работает хорошо

default_statistics_target=100
...
Рейтинг: 0 / 0
25.12.2008, 13:20
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35735576
Алкаш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алкаш
Гость
А ещё стоит учитывать, что unix оптимальнее работает на процессах а маздай - на потоках.
В отличие от Оракла, под маздай PostgreSQL не переделывали, насколько я знаю, он и там
работает на процессах. Поэтому он там должен работать медленнее.
...
Рейтинг: 0 / 0
25.12.2008, 17:01
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35737994
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Cane Cat Fisher
Поставьте на Windows VMWare, а на него - тот же самый Linux, что Production. Я в свое время долго не мог поверить в то, что такая комбинация даст какую-то пользу, кроме сексуального удовлетворения, но оказывается это достаточно стабильно и быстро, по крайней мере на 2.8GHz 2GB RAM. Очень рекомендую.


Намного лучше и быстрее будет Virtualbox. У меня, правда, ситуация обратная - под линуксом запускать виндоус (и, разумеется, другие линуксы, штуки три одновременно, притом на ноуте), однако все виндузятники, кому рекомендовал вышеназванный виртуализатор, им довольны.

P.S. А виндоус на виртуалке быстрее нативного :-) Причин тому несколько - хостовый линукс эффективно кэширует ФС и за счет уменьшения кол-ва подключенного оборудования задействовано меньше прерываний в винде (интересно, мелкомягкие это когда-нибудь перепишут? про висту ничего не могу сказать, но вряд ли оно сделано).
...
Рейтинг: 0 / 0
26.12.2008, 23:58
| Ответить | Цитировать | Написать  
Linux vs. Windows
    #35738225
Nick Mazurkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nick Mazurkin
Гость
Должен сказать, что у меня был несколько отрицательный опыт использования как VirtualBox так и MS Virtual PC - я никак не мог установить Oracle 11g на CentOS - инсталляция вылетала с непонятной ошибкой на обоих эмулятор. Под VMWare все прошло замечательно.
...
Рейтинг: 0 / 0
27.12.2008, 14:51
| Ответить | Цитировать | Написать  
25 сообщений из 26, страница 1 из 2
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Linux vs. Windows
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]