Voland69

Это необходимое, но не достаточное условие.
Примерно как знание цифр не откроет перед вами возможность рассчитать прочность конструкции. Нужно ещё и знать сопромат.
Возможно это вам поможет читать и разбираться в чужом коде.
Так что после учебника по синтаксису нужен учебник по Unity.

Этот способ хранения даты тянется ещё с Lotus 1-2-3. Когда Microsoft добавляла дату/время в Excel, то для совместимости использовали тот же формат.
Отсчёт ведётся от 30.12.1899. Целая часть - количество дней, прошедших с этой даты, дробная часть - время. Если дробную часть умножить на 24*60*60, то получим количество секунд с начала дня.
Встроенных функция для преобразования в PostgreSQL нет, так что, видимо, это прямой перенос из чего-то типа MSAccess.
45672.38114849537 соответствует 2025-01-15 09:08:51.230
Получить можно, например, так:

SELECT
  date_lotus,
  '1899-12-30'::date + MAKE_INTERVAL(days => date_lotus::int, secs => ((date_lotus - date_lotus::int) * 24*60*60)::int) AS datetime
  FROM test;

| date_lotus        | datetime            |
| ----------------- | ------------------- |
| 45672.38114849537 | 2025-01-15 09:08:51 |

Почему же тормозит гипервизор на Селероне, десктопном железе и с ZFS, даже не знаю...

FROM pg_stat_activity
WHERE pid IN (SELECT pid FROM pg_stat_activity WHERE state = 'active');

зачем ты in (select используешь на простую проверку where state='...', убери и оставь это условие в основном запросе.

И еще, каждый раз, когда ты не понимаешь почему тормозит, сначала делай explain запроса, как минимум сюда его закинь, так увидишь, используются ли индексы.

Судя по тому что у тебя 20 секунд выполняется примитивный запрос на всего миллионах записях с условием state='...' то у тебя на полях, используемых в условии нет индекса, а без них база перелопачивается вся целиком, и если быстро - значит она закешировалась, а если медленно - другие операции вытеснили ее из кеша.

А не надо ничего хардкодить. И в INFORMATION_SCHEMA лезть тоже необязательно. Берём да используем row_to_json(NEW), и вся структура как на ладошке.

Пример

Получить массив/роусет ключей/значений и пробежаться по нему в цикле - уже не проблема.

Плохо читали.

Specifies the TCP/IP address(es) on which the server is to listen for connections from client applications.

listen_addresses - это адрес сервера, на котором postrgesql слушает подключения от клиентов. К адресам клиентов не имеет никакого отношения.

В общем случае примерно так:

public class BarType
{ }

public class Foo
{
    public static string Bar<T>() => $"Bar() is called with generic: {typeof(T).FullName}";
}

Type type = typeof(Foo);
MethodInfo mi = type.GetMethods().Single(m => m.Name == "Bar" && m.IsGenericMethodDefinition);
MethodInfo genericMi = mi.MakeGenericMethod(typeof(BarType));
object result = genericMi.Invoke(null, []);
Console.WriteLine($"Result: {result}");

>> Result: Bar() is called with generic: Example.App+BarType

RTFM: Type.GetMethod

public class Foo
{
    public static string Bar() => "Bar() is called";
}

var type = typeof(Foo);
var mi = type.GetMethod("Bar", BindingFlags.Static | BindingFlags.Public);
var r = mi.Invoke(null, []);
Console.WriteLine($"Result: {r}");

>> Result: Bar() is called