https://opennet.ru/openforum/vsluhforumID3/40289.html Иван Золотухин исследовал (http://postgresmen.ru/articles/view/83) эффект от обновления PostgreSQL с версии 8.2 до 8.3. Приведены графики, на которых видно заметное улучшение производительности системы за счёт снижения интенсивности работы с дисками. В итоге, после миграции на PostgreSQL 8.3, было зафиксировано снижение общей загруженности сервера в 2-3 раза.<br><br><br>Причины улучшения производительности<br><br>- Читающие транзакции не приводят к проматыванию идентификатора транзакции (xid), соответственно отсутствует запись в pg_clog, которая раньше имела место быть даже при немодифицирующих запросах.- Распределенные checkpoint-ы. PostgreSQL научился "размазывать" процесс синхронизации буферов с файлами данных на диске, более равномерно распределяя нагрузку на систему.- Улучшенные seqscan-ы. Речь идет не только о Syncronized Scans, но еще и о том, что раньше seqscan по большой таблице, которая не лежит в shared_buffers, приводил к вытеснению "грязных" буферов из памяти и PostgreSQL вынужден был прямо сразу запис https://opennet.ru/openforum/vsluhforumID3/40289.html#21 Tue, 26 Feb 2008 09:42:28 GMT &gt;&gt;работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти <br>&gt;&gt;позволить себе все могут, а объем баз у большинства людей вообще <br>&gt;<br>&gt;Покажите, pls, пример настроек конфига postgres, связанных с памятью, при 4-8Гб оперативы <br>&gt;? shared_buffers сколько лучше поставить, а то сильно задирать боязно, уж <br>&gt;больно мало по дефолту стоит. Остальное что-нибудь нужно тюнить, или shared_buffers <br>&gt;увеличить достаточно ? <br><br>Антон, по такому короткому описанию оптимальную конфигурацию указать сложно. Все зависит от ваших данных, характера работы приложения с ними. Грубо, вам можно пытаться увеличивать shared_buffers до 1-2 ГБ, аккуратно измеряя эффект после изменения. Остальные параметры тоже можно тюнить, но вслепую я не решусь о них говорить.<br> https://opennet.ru/openforum/vsluhforumID3/40289.html#20 Tue, 26 Feb 2008 09:37:47 GMT &gt;P.S. Неужели ваша компания предлагает услуги коммерческой поддержки форумов на домашних страничках <br>&gt;и не интересуется корпоративным сектором? Может, я что-то не понимаю, но <br>&gt;как раз мускульщики коммерческого интереса не представляют (за редким исключением). А <br>&gt;найти информацию об использовании постгреса в крупном бизнесе почти нереально, увы. <br><br>Ну чушь какую-то вы говорите. Во-первых, 2-3 ГБ *активных* данных -- это не домашняя страничка. Во-вторых, да, таких инсталляций подавляющее большинство, не вижу в этом ничего плохого. У нас даже большинство клиентов (а это компании среднего размера) с 1С имеет такие базы. В-третьих, из этого не следует, что оставшимся 5% клиентов не нужна помощь. Крупный бизнес тоже использует PostgreSQL, но тщательно это скрывает и зачастую пока не решается использовать его в mission critical задачах, в отличие от компаний среднего размера, которые все же более поворотливы и имеют меньше стереотипов.<br><br>Смею вас заверить, что мало кто лучше астрономов разбирается в оптимизаци https://opennet.ru/openforum/vsluhforumID3/40289.html#19 Thu, 21 Feb 2008 19:19:48 GMT &gt;работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти <br>&gt;позволить себе все могут, а объем баз у большинства людей вообще <br><br>Покажите, pls, пример настроек конфига postgres, связанных с памятью, при 4-8Гб оперативы ? shared_buffers сколько лучше поставить, а то сильно задирать боязно, уж больно мало по дефолту стоит. Остальное что-нибудь нужно тюнить, или shared_buffers увеличить достаточно ?<br> https://opennet.ru/openforum/vsluhforumID3/40289.html#18 Thu, 21 Feb 2008 18:45:52 GMT Постгрес хорош не в качестве записной кннижки, а как СУБД уровня предприятия. И mysql здесь абсолютно не конкурент (низкая надежность, нет набора встраиваемых языков для организации бизнес-логики в СУБД, примитивный планировщик, "прожорливость" по отношению к ОЗУ и процессорному времени, etc.) Сравнивать стоит с ораклом, но утверждение, что на оракле 95% баз помещается в ОЗУ, совершенно несостоятельно. Что касается ниши пхп+мускул, так тут вообще в 95% случаев (не считал, может, и в 99%, просто позаимствовал число у вас) можно без реляционных СУБД обойтись. С ораклом тягаться тяжело, однако крупные проекты можно с успехом реализовывать на постгресе, во многом благодаря его расширяемости и встроенной поддержке скриптовых языков. И при больших базах, которые не помещаются в ОЗУ, постгрес умеет работать, но есть свои проблемы, которые требуют больше или меньше времени на их решение или поиск обходных путей, пока в этом классе задач версия 8.1 выигрывает особенно, когда запросы под эту версию уже оптимизированы) https://opennet.ru/openforum/vsluhforumID3/40289.html#17 Thu, 21 Feb 2008 16:46:08 GMT работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти позволить себе все могут, а объем баз у большинства людей вообще меньше гигабайта, о чем тут говорить. пока люди не перестанут думать о том, что это вырожденный случай, новички будут кричать, что mysql быстрее postgresql, при этом даже не удосуживаясь поменять конфиг и положить всю БД в память. тут даже спорить нечего.<br> https://opennet.ru/openforum/vsluhforumID3/40289.html#16 Thu, 21 Feb 2008 15:24:28 GMT Кстати, сравнивать версии 8.3 и 8.2 некорректно - версия 8.2 медленнее, чем 8.1. К тому же в постгресе четные версии скорее полигон, чем продакшен. Намного интереснее сравнить с 8.1. Кроме того, работа с базой в ОЗУ слишком вырожденный случай. Про планировщик запросов ни слова, видимо, чтобы не вспоминать о грустном.<br> https://opennet.ru/openforum/vsluhforumID3/40289.html#15 Thu, 21 Feb 2008 15:18:48 GMT На выборках из нескольких таблиц версия 8.3 в несколько раз медленнее версии 8.1 с той же базой, да еще на более сложных запросах временами строит кривой план выполнения (в 8.1 на тех же запросах строит нормальный). До промышленного использования версии 8.3 еще немало времени пройдет. Релиз очень интересный, но его надо "доводить до ума". Хотя на серверах с перегруженной дисковой подсистемой стоит уже и задуматься, т.к. нагрузка на диск существенно уменьшилась, что может для кого-то стать спасением.<br> https://opennet.ru/openforum/vsluhforumID3/40289.html#14 Thu, 21 Feb 2008 14:37:56 GMT Но тем не менее - это лучшее что есть у MySQL :)<br> https://opennet.ru/openforum/vsluhforumID3/40289.html#13 Thu, 21 Feb 2008 07:05:38 GMT &gt;Как я понимаю читать надо: "Ну вы сравнили - промышленную СУБД (PostgreSQL) <br>&gt;с СУБД уровня приложений (MySQL) :)" <br><br>Совершенно верно<br><br><br>