Сильно зависит от конкретного выражения. Но альтернатива ему — вычисление этого выражения на клиенте перед отправкой на вставку + поле в БД. Так что по суммарному CPU клиент+сервер разница врядли будет, а вот по нагрузке на диск будет точно.
Ибо это увеличение размера записи, следовательно чтение с диска почем зря, вымывание дискового кеша и замедление всех запросов даже для не связанных в этим полем вещей.
Вообще следует помнить что БД в первую очередь упираются в диск, во вторую в память и только потом уже CPU. Как правило современное серверное железо имеет излишек CPU с точки зрения БД.
Я могу привести контр пример. При большом апдейте помечаются свободными целые страницы. Соответственно фрагментация уменьшается. Тут все спорно. Но опять последовательные апдейты в одной транзакции увеличивают шансы дедлока.
Лично я за апдейты вне транзакций если они логически не связаны. Хотя апдейты зло просто по факту своего наличия в версионнике.
ну дефакто это работа с внутренним бинарным механизма БД, в опять таки бинарном формате. И где гарантия хоть какой то обратной совместимости? В теории даже минорный апдейт билда сервера может сломать возможность восстановить БД. Это скорее не бекап, а некая реплика + HotStandBy. К сожалению репликация и бекапы у постгресса не настолько «взрослые» как, например, его SQL.
правильный бекап это инкрементальный. Типо пока дампим всю базу… потом дампим дельту что за это время пришла… потом еще чуть чуть… и практически к у нас получается что к окончанию бекапа мы видим базу на момент окончания бекапа и начинаем следующий :)
скорее в «начале файла» в том смысле что чем ближе к началу тем лучше. Т.е. когда у вас запись апдейтиться лежавшая в конце файла то ее новая версия ляжет ближе к началу. Очевидно что чем больше «свободное место fill_factor» тем больше шансов что оно окажется ближе к началу файла.
Почему работает «уже 90%» потому что обновляется менее чем 10% базы данных при апдейтах за интервал между автовакуумами. Если у вас апдейты будут менять сразу полтаблицы то конечно от филфактора будет немного проку.
fill_factor работает только если размер «запаса» превышает размер измененой части таблицы между двумя итерациями автовакума для нее.
Даже немного не так… В «правильной ситуации» размер update между автовакумами должен быть некой постоянной величиной… Например у вас между автовакумами обновляется обычно 10% таблицы. Т.е. в нормальном состоянии у вас 10% файла — дырки в которые нельзя писать, просто потому что FSM про них не знает. Поэтому писаться новые будут — увеличивая файл. fill_factor позволяет создать некий запас в который будут помещаться записи, пока FSM прочухает.
Ну вообще делать бекап на уровне файловой системы — моветон. Хотя репликация в постгрессе, учитывая исторические корни тоже получается моветоном… Но обычный pgdump ничего не лочит и транзакционен. правда в случае чего вы потеряете все данные начиная с момента начала дампа.
Обычный вакум не перетаскивает строки. Обычный вакуум может только «подрезать» файл таблицы с конца если все записи в конце файла помеченны как удаленные. Особенно это начинает работать если fill_factor не 100% и все новые записи у вас «месятся» в начале файла. Старые оказываются в конце файла. Индексы как раз не перестраиваются и в этом преимущество обычного вакуума над FULL. У вас в индексе по прежнему все записи показывают на теже смещения в исходном файле таблицы. А вот когда работает FULL то он перемещает строки и индексы «распухают». Поэтому после full стоит делать REINDEX.
Вакуум обычный иногда требует краткосрочный TABLE LOCK или ROW LOCK для того чтобы поменять метаинформацию по файлу таблицы.
Это только если шарик раскрасить — маркеры нанести.
А по траектории — не будет крученый быстрый на нисходящей траектории уходить, только после отскока. а если вращение и скорость определят, плюс сведут время реакции к почти нулю (идеальная механика), то тут человек проиграет. Так что я ставлю на «подача — прием — сопля/партизан» — только так человек выиграет.
Да не нет там никакого нарушения оферты. Это «вы просто не на тот ценник поглядели». Вот ценник за ваш товар видите в начале ряда… А это от дешевого варианта… а он видимо кончился".
Увы только сличения кода на штрихкоде и на ценнике хоть как то может помочь.
Я бы уточнил температуры не низкие. Они «разные». Тепературный режим аппарата одна из сложнейших инженерных проблем при его конструировании. Один край греется от солнца, другой излучает — остывает, все это вращается и то в свету то в тени. Причем тут не Земля — при перегреве нельзя «включить вентилятор» и побыстрому обдутся. А потом улетел за орбиту Марса или Юпитера и все надо наоброт греться.
Ну не только лампа определяет, но еще и дизайн светильников и их размещение в помещении. У меня вот спотов больше чем люстр. А обычная ненаправленая лампочка светит зачемто за потолок — «непонятно зачем вообще выпускают лампочки с таким позорным багом» :)
Тут проблема скорее в том что в светильники изначально разрабатываемые для «шаров» ставят по сути споты. Хотя есть и конструкции LED которые стремяться уйти от этого (в форме свечки а сами диоды на такой «стоечке» ). Но все таки правильно для лед лам разрабатывать свои светильники своей формы.
Как раз в низковольтной проводке и беда — она для той же мощности будет как раз толще, более критична к качеству монтажа/соединения и с большими потерями. Так что легкой она не будет. Я вангую что разделят цепи управления и силовые. Т.е. в выключателях будут «тонкие легкие провода» или безпроводные интерфейсы управления. Трансформаторы будут в монтажных коробках над люстрами или на крайняк в монтажках на стене. но цепи питания до них те же 220В.
Ну некоторые их отписавшихся лучшие геймерские годы провели за LodeRunner, Boulderdash, Packman на каком нибудь БК-001 где графика в прямом смысле была условна. Не говоря уже про текстовые «стратегии». А Вольфенштейн на IBM PC был чем то за гранью реальности. Кстати именно его и первые думы мне напоминает майнкрафт. Так что по «красивой» графике не соглашусь. В игре графика не столько важна. Хотя наверное встречают по одежке и игры тоже. А вот уже сам игровой процес.
взрыв ядерной бомбы, который снёс пол континента
которую надо «крафтить» в течении 8 часов реального времени.
Что и огорчает. Если службам дадут команду «ФАС» — посадят всех и надолго. Побороть? Ну свалить из страны в какие нибудь штаты, а там стать большим начальником, а потом напать на россию.
Выдадут тебе штраф ты его оплатишь.
Но вместе со штрафом выдадут предписание суда «устранить». А вот за невыполнение предписания суда могут и срок дать…
Ибо это увеличение размера записи, следовательно чтение с диска почем зря, вымывание дискового кеша и замедление всех запросов даже для не связанных в этим полем вещей.
Вообще следует помнить что БД в первую очередь упираются в диск, во вторую в память и только потом уже CPU. Как правило современное серверное железо имеет излишек CPU с точки зрения БД.
Лично я за апдейты вне транзакций если они логически не связаны. Хотя апдейты зло просто по факту своего наличия в версионнике.
Почему работает «уже 90%» потому что обновляется менее чем 10% базы данных при апдейтах за интервал между автовакуумами. Если у вас апдейты будут менять сразу полтаблицы то конечно от филфактора будет немного проку.
Даже немного не так… В «правильной ситуации» размер update между автовакумами должен быть некой постоянной величиной… Например у вас между автовакумами обновляется обычно 10% таблицы. Т.е. в нормальном состоянии у вас 10% файла — дырки в которые нельзя писать, просто потому что FSM про них не знает. Поэтому писаться новые будут — увеличивая файл. fill_factor позволяет создать некий запас в который будут помещаться записи, пока FSM прочухает.
Обычный вакум не перетаскивает строки. Обычный вакуум может только «подрезать» файл таблицы с конца если все записи в конце файла помеченны как удаленные. Особенно это начинает работать если fill_factor не 100% и все новые записи у вас «месятся» в начале файла. Старые оказываются в конце файла. Индексы как раз не перестраиваются и в этом преимущество обычного вакуума над FULL. У вас в индексе по прежнему все записи показывают на теже смещения в исходном файле таблицы. А вот когда работает FULL то он перемещает строки и индексы «распухают». Поэтому после full стоит делать REINDEX.
Вакуум обычный иногда требует краткосрочный TABLE LOCK или ROW LOCK для того чтобы поменять метаинформацию по файлу таблицы.
Вообщем про это достаточно подробно рассказывал Брюс Момджан на HL++ 2013 www.highload.ru/2012/abstracts/410.html про вакуум начинается с 44 слайда.
Аш назг дурбатулук, Аш назг гимбатул, Аш назг тракатулук, Ак бурзум иши кримпатул.
Как то так (:
А по траектории — не будет крученый быстрый на нисходящей траектории уходить, только после отскока. а если вращение и скорость определят, плюс сведут время реакции к почти нулю (идеальная механика), то тут человек проиграет. Так что я ставлю на «подача — прием — сопля/партизан» — только так человек выиграет.
Увы только сличения кода на штрихкоде и на ценнике хоть как то может помочь.
Тут проблема скорее в том что в светильники изначально разрабатываемые для «шаров» ставят по сути споты. Хотя есть и конструкции LED которые стремяться уйти от этого (в форме свечки а сами диоды на такой «стоечке» ). Но все таки правильно для лед лам разрабатывать свои светильники своей формы.
которую надо «крафтить» в течении 8 часов реального времени.
Но вместе со штрафом выдадут предписание суда «устранить». А вот за невыполнение предписания суда могут и срок дать…