In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.то на самом деле имеется в виду "InnoDB uses this primary key value to search for the row in the clustered index only." Когда-то давно, ещё в версии, вроде бы, 5.6, я даже не поверил и проводил специальный проверочный эксперимент, который подтвердил этот бред...
Время выполнения запроса не сильно критичное, но тем не менее - 0,1625
WITH cte AS (
SELECT current_point_n <-> LAG(current_point_n) OVER (ORDER BY date_add) single_length
FROM positions
WHERE date_add BETWEEN '2021-01-07 00:00:00' AND '2021-01-07 23:59:59'
)
SELECT SUM(single_length) total_length
FROM cte;CREATE FUNCTION update_point()
RETURNS trigger
AS $update_point$
BEGIN
NEW.current_point_n := st_geometryfromtext('POINT('|| NEW.latitude ||' '|| NEW.longitude ||')',4326);
RETURN NEW;
END;
$update_point$ LANGUAGE plpgsql;
CREATE TRIGGER update_point
BEFORE INSERT OR UPDATE
ON positions
FOR EACH ROW EXECUTE PROCEDURE update_point();когда сервер был перезапущен, но порт остался занятСервер перезапущен - в смысле рестарт ОС? тогда смотрите, какая ещё дрянь в автозагрузке хавает, а потом отпускает порт. Ибо сохранение занятия порта при рестарте ОС - это сказки.
По идее если сервис падает, то он освобождает порт.Это с чего бы? для освобождения порта надо, чтобы сведения о падении обработчика дошли до сетевой подсистемы... а то она может быть и не в курсе. Или модуль какой достаточно автономен от приложения и не выгружается с ним безусловно.
Как еще можно решить проблему с перезапуском?Преобразовать приложение в службу - и пусть диспетчер служб перестартовывает... но для этого чётко разберитесь с кодом своего сервиса - он должен при выгрузке по любой причине освобождать ресурсы.
Ты же понимаешь, что CTE может вернуть десяток записей с dm_rank = 1? тут нужно применять ROW_NUMBER() и расширять сортировку до обеспечения уникальности записи.
Это даже если не нудеть о том, что вот никакое ограничение в структуре не мешает d.date_latest_message не соответствовать максимальному DM.added_date.
Да ладно! легко эмулируется на коррелированном группирующем подзапросе. Другое дело производительность - работа с переменными всегда однопроходный фуллскан, а группировка может и индексы подтянуть, так что вопрос, какой вариант производительнее, упирается в среднее количество записей на группу.