Думаю, эти понятия к данному изделию пока не применимы. Пуля вылетает по гладкому (судя по всему) стволу со скоростью 40м/с. По отметинам на мишенях понятно, что она барахтается в полете, как ей вздумается (что не удивительно при такой-то энергетике). ИМХО, аппарат пригоден пока для послеобеднных пострелушек в офисе.
Боюсь, с такой энергетикой он еще долго не сможет конкурировать с пневматикой (мой «крикет» плюется 40Дж). И, судя по тому, что почти все пули разворачивались, ствол гладкий. Значит, заменив его на нарезной, получим еще меньшую начальную скорость пули. Настолько малую, что пули будут просто застревать в стволе.
Возьму ваш опыт на заметку. От себя добавлю, что неплохой прирост производительности можно получить, если все же докупить несколько хардов и раскидать на них таблицы, логи и индексы (каждому — свой хард).
Эта возможность начинать и прекращать обход глобала с любого конкретного индекса и на любом уровне вложенности индексов является уникальной функцией глобалов MUMPS.
Вообще, кто работает с highload sql-базами знает, что сортировка — дорогая операция…
Вот этот код вызывает вопросы:
s company=”B~”
f s company=$o(^Employee(company)) quit:$e(company,1) ’= ”C” do
. ; сделать что-нибудь с записью
Сначала вы пишите, что стоит задача найти все записи, начинающиеся с «С». А после кода такой комментарий:
Если первая буква названия компании не “C”, выйти из цикла
Т.е. при первом же несовпадении происходит выход из цикла (и судя по коду, это верно).
Я чего-то не понимаю?
Получается, что история «Терминатор» — это слабая предопределенность. Как skynet не пытался убить Джона Конора, он был обречен на провал, ведь в будущем Конор существует и, значит, все попытки заранее обречены на провал.
А вы посмотрите analyze для этого запроса — запрос должен сразу перебрасываться на нужную партицию. А cost для обоих запросов должен совпадать. У меня тоже была подобная бага, индекс как-то криво создался чтоли. Пересоздал индекс — все заработало как нужно.
Тут у меня правда, есть предположение, что утилита не взлетела, хотя все по инструкции сделал. Ну да Бог с ней. Посыл моего поста заключается в том, как убедиться, что планировщик выбрал оптимальный путь.
В первом случае >=, а во втором <.
Это скорее аргумент за масштабирование, не?
Вообще, кто работает с highload sql-базами знает, что сортировка — дорогая операция…
Именно. Такой цикл завершится при первом же несовпадении и не найдутся ВСЕ записи, начинающиеся с «С».
s company=”B~” f s company=$o(^Employee(company)) quit:$e(company,1) ’= ”C” do . ; сделать что-нибудь с записьюСначала вы пишите, что стоит задача найти все записи, начинающиеся с «С». А после кода такой комментарий:
Т.е. при первом же несовпадении происходит выход из цикла (и судя по коду, это верно).
Я чего-то не понимаю?
Заметил, что часто такое поведение наблюдается, когда по этим индексам идет партицирование таблиц.