| 
|  | | 2.2, takem (?), 17:40, 24/03/2015 [^] [^^] [^^^] [ответить] | +8 +/– |  | смотря как готовить, но да, быстрее, надежнее и вообще лучшее 
 |  |  | 
 | 2.5, ъ (?), 17:56, 24/03/2015 [^] [^^] [^^^] [ответить] | +6 +/– |  | По совокупности: - При росте БД у постгреса более предсказуемое управление данными, сноуболинг не происходит из-за особенностей ядра. Как следствие на очень малых объемах постгрес работает так же как и на больших, но это заметно только до 100-200 мб.
 - Продуманная безопасность у постгресса и нет необходимости перезагружать боевую БД для получения привилегированного доступа.
 - Оптимизатор в ядре разрабатывался научным сообществом (с оглядкой на мировых лидеров - таких как оракл и сайбейс), а не только программистами как у мускуля (на конференции СанДейз они очень извинялись за качество кода и алгоритмы в мускуле - так как у них энтерпрайз план и включается в код только то, что одобрено руководством, а так же фичи не принимаются если это идет в разрез с энтерпрайз планом - что и привило к расколу)
 - Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгреса, что снимает почти всю головную боль с администраторов БД и разработчиков.
 - Управление кэшем не пытающимся на себя взять функции ядра ОС, каждый делает только свою часть, но делает это отлично.
 - Есть множество примеров где постгрес лучше. Только вот на хостингах он встречается реже и по тому стоит чуть-чуть дороже, что и приводит к меньшему распространению.
 
 |  |  | 
 |  | |  | | 4.9, Аноним (-), 22:44, 24/03/2015 [^] [^^] [^^^] [ответить] | +/– |  | Соглашусь с оратором. Partitioning в постгре отсутствует, в мускуле - достаточно развит и решает поставленные перед ним задачи. 
 |  |  | 
 | 4.10, Аноним аля (?), 07:36, 25/03/2015 [^] [^^] [^^^] [ответить] | +/– |  | > Range-партиции триггером - страшный стыд. Не триггером, а совокупностью штатных методов, главный из которых в данном случае - наследование таблиц.  Чего в MySQL нет в принципе.
 |  |  | 
 |  | | 5.12, Аноним (-), 16:51, 25/03/2015 [^] [^^] [^^^] [ответить] | +/– |  | IF ( NEW.logdate >= DATE '2006-02-01' AND NEW.logdate < DATE '2006-03-01' ) THEN
 INSERT INTO measurement_y2006m02 VALUES (NEW.*);
 Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования, приходится извращаться. Даже в официальной документации.
 |  |  | 
 |  | | 6.17, Аноним (-), 19:45, 25/03/2015 [^] [^^] [^^^] [ответить] | +/– |  | >     IF ( NEW.logdate >= DATE '2006-02-01' AND >          NEW.logdate < DATE
 > '2006-03-01' ) THEN
 >         INSERT INTO measurement_y2006m02 VALUES
 > (NEW.*);
 > Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
 > кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
 > приходится извращаться. Даже в официальной документации.
 У постгрес просто нет синтаксиса для управления partitioning, но это не мешает ему там работать.
 |  |  | 
 | 6.22, asdasd (?), 10:33, 26/03/2015 [^] [^^] [^^^] [ответить] | +3 +/– |  | Mysql-дрочеры задолбали своими тупыми комментами и попытками хоть чтото положительное найти в своей недодб. Одно когда используешь его поскольку приходится, другое когда пытаетесь найти эфемерные преимущества изза неумения-нежелания вклбчить моск >     IF ( NEW.logdate >= DATE '2006-02-01' AND 
>          NEW.logdate < DATE
 > '2006-03-01' ) THEN
 >         INSERT INTO measurement_y2006m02 VALUES
 > (NEW.*);
 > Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
 > кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
 > приходится извращаться. Даже в официальной документации.
 |  |  | 
 | 
 | 
 | 4.23, ъ (?), 17:52, 27/03/2015 [^] [^^] [^^^] [ответить] | +1 +/– |  | Предлагаю обсуждать партиции с теми кому их приходится создавать и поддерживать. В оракле создайте доп. рейндж партицию или расширте набор  хеш-партиций - удобно? В мускуле добавте гранулярности партициям или наследуйте другие условия на субпартиции. ТО, что механизм в явном виде использует более длинный синтаксис (только больше набирать на клавиатуре, если не умеете автоматизировать) не повод ругать очень ГИБКУЮ систему. Експлейн на партицированые данные покажет реальную статистику и использует отдельные гистограммы. Если у вас реально отношение вставок к выборкам разбалансированно возможно стоит трезво оценить решение и использовать nosql + etl к примеру.
 
 |  |  | 
 | 
 | 3.11, Аноним (-), 11:57, 25/03/2015 [^] [^^] [^^^] [ответить] | +/– |  | > партицирование на сегодняшний день самое лучше и продуманное у постгреса, Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.
 |  |  | 
 |  | | 4.15, Аноним (-), 19:42, 25/03/2015 [^] [^^] [^^^] [ответить] | +/– |  | >> партицирование на сегодняшний день самое лучше и продуманное у постгреса, > Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.
 Это не совсем так.
 |  |  | 
 | 
 | 
 | 2.24, XoRe (ok), 01:26, 30/03/2015 [^] [^^] [^^^] [ответить] | +/– |  |  > Подскажите знающие, postgresql быстрее mysql? Если вам сказать "да, быстрее", вы броситесь его изучать и переписывать сайты с mysql на postgres?
 |  |  | 
 | 
 
 
 | 1.4, amix (ok), 17:47, 24/03/2015  [ответить] [﹢﹢﹢] [ · · · ] | –7 +/– |  |  Не быстрее не надежнее и не лучше, все зависит только от того как готовить. 
 |  |  | 
 
 | 1.7, o (?), 18:20, 24/03/2015  [ответить] [﹢﹢﹢] [ · · · ] | +/– |  | Да постгрес хорош. И академичен и развивается. А еще меня попросили, почистить место. Там постгрес статистику с приборов в сушильном цехе хранит. 8 лет назад был запущен, так и работает.
 
 |  |  | 
 
 | 1.18, Аноним (-), 20:05, 25/03/2015  [ответить] [﹢﹢﹢] [ · · · ] | +/– |  | > запасной сервер переводится в состояние заморозки БД для бэкапа Какое ещё «состояние заморозки БД для бекапа»? Что за ерунда написана?
 |  |  | 
 
 | 1.19, Аноним (-), 20:08, 25/03/2015  [ответить] [﹢﹢﹢] [ · · · ] | +/– |  | > Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции. с последнего checkpoint скорее всего, а не commit.
 |  |  | 
 
|  | | 2.21, Andrey Mitrofanov (?), 10:14, 26/03/2015 [^] [^^] [^^^] [ответить] | +/– |  | >> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции. > с последнего checkpoint скорее всего, а не commit.
 Нет, коммита. По WAL-логам.
 И нет, не с "последней зафиксированной", а с последней _общей точки историй двух серверов.
 Слайд#25:
 [CODE]Start recovery from the point of divergence, not
some later checkpoint.[/CODE]
 [И судя по этому "not ... checkpoint" вплоть до откатывания чекпоинтов, не доехавших до нового мастера.]
 |  |  | 
 | 
 |