WITH RECURSIVE
cte (id, parent_id, path) AS (
SELECT id, NULL, id
FROM table
WHERE parent_id IS NULL
UNION ALL
SELECT t.id, t.parent_id, c.path || t.id
FROM table t
JOIN cte с ON t.parent_id = c.id
)
SELECT c1.id, c1.parent_id, COUNT(*)
FROM cte c1
JOIN cte c2 ON c2.path LIKE c1.path || '%'
GROUP BY 1, 2может кто знает способ в постгресе создавать временные таблицы для расчетов
У всех нормальных провайдеров вы в один хоп получаете ваш ближайший гейтвей у него, дальше 2-3 хопа в сети провайдера и выход за его пределы.
Это всегда в 100% случаев одна и та же трасса.
Провайдер говорит, что на его стороне пинги проходят ровно.
Два офиса соединены выделенным каналом.
Во втором также с полотка кабель идёт в другой коммутатор, а от этого коммутатора в роутер выступающий шлюзом для обоих офисов.
роутер выступающий шлюзом для обоих офисов.
При этом если выключить роутер, то теряется связь между офисами. Я не могу догадать, какую роль в такой схеме выполняет роутер?
У нас данный сервер выступает в качестве шлюза
В таком случае лучше перед ним поставить маршрутизатор и подключить провайдера к маршрутизатору, верно?
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
Ключ LsaCfgFlags=0
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard]
Ключ LsaCfgFlags=0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard]
Ключ EnableVirtualizationBasedSecurity - удалить
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard]
Ключ RequirePlatformSecurityFeatures - удалитьи запрос перестал видеть предыдущие строки.
Существующую сигнатуру GetPD менять возможности нет, она зависит от ItemId и ReportDate, а то что она иногда получает предыдущее значение из PDIndicatorsHistory - редкая ситуация.
В нашей системе оказалось жесткое ограничение по глубине рекурсии, поэтому рекурсивные методы не подойдут.
OPTION (MAXRECURSION 0). что конкретно не понятно в поставленной задаче ?
Но есть опционная переменная temp_buffers, которая определяет количество памяти под временные таблицы на одно соединение. Если размер временных таблиц сессии не превосходит указанного объёма, то их данные полностью кэшированы в памяти, и соответственно скорость работы с ними высокая.
Значение переменной можно установить как постоянно для всех сессий (в postgresql.conf), так и индивидуально для текущей сессии (SET temp_buffers = 'XXX';).
См. https://postgrespro.ru/docs/postgresql/17/runtime-...
На всякий случай рекомендую помнить, что временные таблицы не вакуумятся, так что для интенсивно изменяющейся таблицы без явного ANALYZE планировщик может использовать устаревшую статистику данных и выдавать неоптимальный план. А без VACUUM - и вылететь за выделенный объём памяти за счёт неочищенного пространства. Так что явный VACUUM ANALYZE temp_table; может быть небесполезной операцией.