Вопросы по MasterSCADA 4D

[AlexBut]

Спасибо asuwcc:
"FILETIME - This structure is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601.
Нужно взять количество наносекунд с января 1970 года до 1601 (-116444683000000000) и отнять его (по модулю) от времени в БД. Часовой пояс надо учесть."
И тогда старшие 10 цифр это время в Unix в сек, а остаток умножить на 10в степени-7 -доли секунды

[AlexBut]

Здравствуйте!
Настроил Основной архив данных в MS4D на PostgreSQL .
И т.к. проект большой БД быстро разрастается -уже 13 ГБ хотя всего несколько дней работает.
Реально растёт только одна таблица- public.data_raw в Schemas.
Вручную удалил строки в public.data_raw,где source_time <133492879000000000 т.е. 09.01.2024 17:00:00 (т.е. по нашему времени 10.01.2024 00:00:00)
Скрипт: Delete from public.data_raw where source_time <133492879000000000
и действительно на графиках удалились данные более старые чем это время.
Но размер таблицы и в целом БД не изменился-как был 13 ГБ так и остался?
Я ожидал, что размер сильно уменьшится, но что-то не так?
Подскажите, пож-та

[AlexBut]

И позвольте ещё вопрос- удалились данные на трендах до 09.01.2024 22:30, хотя я ожидал, до 10.01.24 00:00:00.
Несколько раз пересчитывал source_time <133492879000000000 т.е. 09.01.2024 17:00:00 (т.е. по нашему времени 10.01.2024 00:00:00 т.к. у нас UTC+7)
Хотя это уже не так принципиально, но почему так?
Спасибо

[asuwcc]

Но размер таблицы и в целом БД не изменился-как был 13 ГБ так и остался?
Я ожидал, что размер сильно уменьшится, но что-то не так?

День добрый.

Попробуйте применить команду VACUUM к таблице.
Или настроить Autovacuum в postgresql.conf
autovacuum = on # Enable autovacuum subprocess? 'on'

[onimor]

Вам точно нужно столько данных? может их сократить или период записи уменьшить.
На крайняк можно подумать сколько строк вы хотите видеть и программой в скаде проверять количество. Если будет больше то удалять остальное.
К примеру хотите видеть 50к , программа раз в 10 минут проверяет и обнаруживает, что уже 80к, идет и удаляет 30к старых.
В таком случае роста не должно быть и без вакума

[onimor]

Хотя это уже не так принципиально, но почему так?

А так пробовали?

where source_time>= timestamp '2024-01-01 00:00:00'
and source_time< timestamp '2024-01-10 00:00:00';

или

where source_time>= make_timestamp(2024,1,1,0,0,0)
and source_time< make_timestamp(2024,1,10,0,0,0);

[imaex]

Здравствуйте!
Но размер таблицы и в целом БД не изменился-как был 13 ГБ так и остался?
Я ожидал, что размер сильно уменьшится, но что-то не так?

Странно, что Вы этого ожидали. Я бы наоборот - сильно удивился, если бы размер уменьшился. Хоть и никогда конкретно с PostgreSQL дела не имел. Вам надо доку по администрированию PostgreSQL читать.

[AlexBut]

А так пробовали?

или

Пробовал но у source_time тип bigint

[AlexBut]

День добрый.

Попробуйте применить команду VACUUM к таблице.
Или настроить Autovacuum в postgresql.conf
autovacuum = on # Enable autovacuum subprocess? 'on'

Да получилось, спасибо

[Ready]

И позвольте ещё вопрос- удалились данные на трендах до 09.01.2024 22:30, хотя я ожидал, до 10.01.24 00:00:00.

133492879000000000 = 2024-01-09T15:31:40+00:00 = 2024-01-09T22:31:40+07:00

Для Вашей даты source_time = 133492932000000000 = 2024-01-09T17:00:00+00:00 = 2024-01-10T00:00:00+07:00