Задача из разряда "У меня в подполе происходит стук"...
на проде, скопировать миллионы строк из одной таблицы в другую
Таблицы - в рамках одной БД? одного инстанса MySQL? Одного хоста? Одного гипервизора? иное?
Размер одной записи? соответственно общий объём к копированию/переносу?
проверяя при вставке есть ли такая запись.
Полная проверка записи? по значению выражения первичного или некоего уникального индекса? По значению иного выражения? или критерий дублирования - множественный? в последнем случае - все ли варианты выражений индексированы?
Структура таблиц, набор полей разные.
Имеется ли полная поддержка значениями по умолчанию для полей, отсутствующих в копируемой структуре?
И о ненаписанном - имеются ли на целевой таблице триггеры? имеются ли в ней CHECK CONSTRAINT / Foreign key, способные вызвать violation безотносительно к дублированию данных в рамках заданного критерия дублирования?
Ага... а гильотина - лучшее средство от насморка. Ну неужели трудно настроить файрвол и указать, что PostgreSQL имеет право принимать входящие соединения?
Ну так соберите все координаты (пофиг, начальные они или конечные), пронумеруйте всквозную, затем превратите отрезки в рёбра (а пронумерованные точки - это соответственно узлы) графа и решайте стандартную задачу поиска путей в графе.
Условно отрезки могут иметь общую точку в своей "середине"
Не понял... это что, при движении от точки 0 к точке 1 можно пойти "синим" путём, а потом в точке пересечения перескочить на "красный", что ли? тогда дополнительно следует найти все точки пересечений и включить их в граф как узлы.
А если нет - то какая разница, пересекаются отрезки визуально или нет?
sergey_privacy, Увы, у меня аналогичные железяки - Huawei S9300. У которых способ представления документации - вообще обняться и плакать, а искать там что-то... не, по работе бы ещё полез, куда деваться, но просто так...
Что нужно получить, если нужная дата не соответствует ни одному (DateFrom-DateTo) для какого-то Item?
Что нужно получить, если нужная дата соответствует более чем одному (DateFrom-DateTo) для какого-то Item?
Если собираетесь сказать "такого не может быть" - докажите это публикацией структуры таблицы. в которой будет соответствующий constraint, блокирующий наличие подобных ситуаций. Если такого ограничения нет, то обе указанные мной ситуации - возможны (например, как последствие сбоя или случайного/злонамеренного изменения). На клиентскую логику не кивайте - она не влияет.
Rsa97, я бы сказал ".. и дополнительно ещё один раз колонку dic_type.name".
bgood, ну так указывайте конкретные поля, которые нужны, по одному. Тогда не будет проблем и вопросов "А это откуда?"...
Авось руки-то не отвалятся. А то взяли, понимаешь, моду облегчать себе жизнь и лепить звёзды где надо и где не надо... Вообще-то везде, кроме COUNT(*) - не надо.
Тут нет вообще никаких лазеек для оптимизации. Ну за исключением случая, когда регулярка вообще не меняется не то что каждый день, а в принципе всегда абсолютно такая. Тогда следует добавить в структуру таблицы вычисляемое поле с этим регэкспом, и отбирать по значению этого поля. Либо, если изменение структуры нежелательно, создать дополнительную таблицу, связанную 1:1 по выражению ключевого или любого уникального индекса плюс поле с этим регэкспом, пересчёт поддерживать триггером.
Альберт Ушаков, ну так описывайте задачу, а не свои попытки её решить. Исходная структура (CREATE TABLE таблиц, не влияющие на задачу поля поудалять), пример данных (INSERT INTO, 3-5 записей на таблицу), требуемый результат для таких данных и детальные пояснения. Ну и само собой, смысл происходящего - что собственно считаем.
мне интересно почему так произошло. Изменений насколько я понимаю не было.
"Я ничего не делал, оно само!"
Изменения - были. И ты собственно их нашёл/вычислил. Причём они произошли в таком месте, изменения в котором даже на обновление Windows не спишешь (очень теоретически - можно списать на обновление этого самого ПО - но разработчик очень быстро скажет, возможно ли подобное). А потому я бы заставил клиента жёстко найти того, кто эти изменения сделал, и допросить с пристрастием, на зачем это было сделано. Халатность, бездумность, идиотизм или сознательная диверсия - это и самому клиенту будет полезно узнать...
И даже не сомневайся - изменения внесены вполне определённым человеком, руками.
Агрегатные функции (SUM) есть, но GROUP BY нет - т.е. весь набор записей трактуется как одна группа. Но в этих условиях выбирать одно значение из всей группы (для SELECT *), причём заведомо от фонаря какое - совершенно бессмысленное мероприятие.
В общем, лучше определитесь с логикой происходящего - пока её просто нет. Оптимизировать же нечто не имеющее смысла, точно так же бессмысленно.
Ну идут потери пакетов, отсюда лаги. Замеры скорости ничего не скажут, надо именно процент потерь смотреть, причём не ICMP. Для начала убедитесь, что проблема не локальная - что она как минимум наблюдается на двух разных устройствах, причём подключенных по меди, а не по воздуху.
админ, у которого такая железка под рукой, мог глянуть данные, ответить и вопрос был бы закрыт.
Вот у меня, скажем, есть аналогичные железки - но я не представляю, как "глянуть данные". На самой железке табло "Сейчас я жру столько-то" - нету, смотреть загрузку четырёх УПСов, на которых сидит в общей сложности 11 единиц оборудования, бессмысленно, а тормозить девайсы и перестёгивать их так, чтобы можно было померить, что в данный момент кушает один девайс - да щазз! вот мне больше заняться нечем кроме как яму себе копать.
А ещё - вот у меня две такого плана железки, и по набивке корзин у них потребление будет различаться, я думаю, где-то вдвое (а с учётом реально используемых портов - может, и втрое). Ну скажу я тебе навскидку "600 и 1500 Вт" - сильно поможет?
Таблицы - в рамках одной БД? одного инстанса MySQL? Одного хоста? Одного гипервизора? иное?
Размер одной записи? соответственно общий объём к копированию/переносу?
Полная проверка записи? по значению выражения первичного или некоего уникального индекса? По значению иного выражения? или критерий дублирования - множественный? в последнем случае - все ли варианты выражений индексированы?
Имеется ли полная поддержка значениями по умолчанию для полей, отсутствующих в копируемой структуре?
И о ненаписанном - имеются ли на целевой таблице триггеры? имеются ли в ней CHECK CONSTRAINT / Foreign key, способные вызвать violation безотносительно к дублированию данных в рамках заданного критерия дублирования?