Да, согласен. Ведь получается что все дерево индекса проходит дополнительную обработку.
Но в случае когда поле просто участвует в селекте, вида SELECT time FROM tbl WHERE category_id = 123 выборка будет быстрее, т.к. таблица меньшего размера = меньше IO и преобразования необходимы только для выбранных строк, а не всего индекса.
Опять же, случаи бывают разные. Но все равно спасибо :)
Перечислите пожалуйста несколько, кроме того, что данные хранятся в UTC.
Единственный минус, который увидел для себя — ограничение по дате 2038 годом. Зато занимает 4 байта вместо 8 и выборки по ним происходят быстрей (экономия на спичках, но все же).
Спасибо. Давно не читал таких очевидных вещей + копипасту из документации.
Вы бы подумали о сборщике мусора в том же ИЕ6. Он с ума сойдет от такого количества контекстов, которые ему придется хранить.
С встраиванием в PHP (не патчем) он стал поддерживать эту технологию. Уже несколько месяцев стоит на серваках (еще 5.3.2-dev стянутый с свн), полет нормальный
Если гиганты что-то используют ифреймы, это не значит что это круто и его можно использовать.
У фейсбука яваскрипта на 1мб, который грузится сразу же. Так что, теперь можно забить на размеры JS?
Тут начинаются догадки, т.к. с сетевыми дисковыми хранилищами не игрался.
Смотрели в сторону GFS, Lustre? Сами диски в каком-либо RAID массиве? SATA, SAS, SSD?
NFS не самый лучший выбор для таких нагрузок. Чем обусловлен выбор одного стореджа вместо нескольких? Может сделать хранение распределенным и не держать все на одном диске?
Хм, разве краулеры стали считать iframe и саму страницу одним единым? Насколько я помню, то как раз наоборот. И некоторые приемы SEO применяют перевод контента в ифрейм, чтоб убрать мусор со страницы.
Систему мониторинга какую-нибудь используете? Если да — что показывают графики в моменты нагрузки? iowait растет в моменты пиков? Что показывает top, iotop? Внутри сервера аппликухи общаются через unix-сокеты или по tcp?
Похоже на затыки дисков или сокетов.
Но в случае когда поле просто участвует в селекте, вида SELECT time FROM tbl WHERE category_id = 123 выборка будет быстрее, т.к. таблица меньшего размера = меньше IO и преобразования необходимы только для выбранных строк, а не всего индекса.
Опять же, случаи бывают разные. Но все равно спасибо :)
Единственный минус, который увидел для себя — ограничение по дате 2038 годом. Зато занимает 4 байта вместо 8 и выборки по ним происходят быстрей (экономия на спичках, но все же).
Вы бы подумали о сборщике мусора в том же ИЕ6. Он с ума сойдет от такого количества контекстов, которые ему придется хранить.
Конечно плагин плагину рознь…
Еще помнится заводной саундтрек. Эх…
То что нужно. Ждем появления на рынке
У фейсбука яваскрипта на 1мб, который грузится сразу же. Так что, теперь можно забить на размеры JS?
Смотрели в сторону GFS, Lustre? Сами диски в каком-либо RAID массиве? SATA, SAS, SSD?
Похоже на затыки дисков или сокетов.