MySQL 5.0 RC1

> То кто-то придумал какой-то VACUM в MySQL 5.0
не знаю почему тот чувак пятерку вспомнил,
но OPTIMIZE TABLE для InnoDB что делает ?

>То MVCC нет - не называется это MVCC но тем не менее Innodb основан на подобных принципах
речь про MaxDB шла, где ты там InnoDB видел ?)

> с автоматическим пурджингом
кури Free Space Map и autovacuum
> большим набором режимов изоляций
залепа, особено SERIALIZABLE

>> В postgresql есть таблицы типа myisam? :) >fsync ему отключи будет нечто похожее по скороси и падучести :)))

От отключения fsync-а падучести не прибудет, но база получает шанс навернуться при падении питания. У меня похожее было с scsi raid-5 в режиме write-cache без батарейки

>тем не менее для хостингов нет реальной альтернативы MySQL / Postgres >она только функционально мощнее - спору нет / не на маленьких хостингах >а вообще почти на всех стоит MySQL / это неописуемо сколько там баз на >1 сервер приходится и сколько запросов обрабатывается (и сколько >одновременный соединений она держит) / черт с ними с сыпящимися базами >- они восстанавливаются легко / зато быстро

Ну предположим делается на каком-то конкретном сервере 100 запросов в секунду - select/update/delete/insert, все по индексам, все по мааленькому количеству matching-rows. В это умение mysql/innodb я могу поверить. Теперь добавим какого-то новоиспечёного php-писаку, который делает ошибку и его скрипт уходит в бесконечный цикл - не важно с чем. Хотя бы с бекапом. Что происходит с 100queries/second ? Я например знаю. Для меня результат - переход на PostgreSQL. Note - перед этим я именно этот проект на mysql/innodb продавал и оптимизировал примерно 3 года.

Resume - тупой бекап убивает скорость "быстрых" запросов на mysql/innodb в 3-5 раз. В постгресе гонял, всё пучком.. делаем бекап, параллельно какой-нибудь data import на 1m rows.. vacuum analyze.. Web продолжает чеканить 50..200 queries/second.