Популярные расширения на PostgreSQL

[Suvitruf]

TimescaleDB

Лучше сразу возьмите Кликхауз, если вам временные ряды нужно хранить.

[ptr128]

Если нужна все же RDBMS, то ходить к CH через FDW может оказаться менее эффективней, чем к TimescaleDB напрямую.

[Melkij]

Опять чатгпт писал?
Комментарии к pg_stat_statements.track и track_activity_query_size просто неверны, а требуемый для активации pg_stat_statements shared_preload_libraries вовсе не упомянут.
total_time в pg_stat_statements давно уже нет, во время добавления total_plan_time (если включен pg_stat_statements.track_planning) был переименован в total_exec_time.

[AzriMan]

Видимо да :)

Потому что есть ещё нестыковки. Например, автор статьи ссылается на функцию ST_DWithin:

Допустим, у нас есть база данных мест с интересными объектами (например, кафешки, музеи, парки), и мы хотим найти ближайшие к заданной точке. Это классическая задача для PostGIS, которая решается с использованием функции ST_DWithin:

WITH service_areas AS (
  SELECT service_id, ST_Buffer(location, radius) AS area
  FROM services
)
SELECT service_id, ST_AsGeoJSON(ST_Union(area)) AS coverage_area
FROM service_areas
GROUP BY service_id;

И пишет дальше про другие функции, значение радиуса, точки:

В запросе используем ST_DWithin для фильтрации объектов в радиусе 1000 метров от заданной точки, в кач-ве примера тут ред сквер. ST_MakePoint создает геометрическую точку, ST_SetSRID назначает этой точке пространственный референс (4326 обозначает WGS 84), а ST_Distance используется для сортировки результатов по расстоянию от заданной точки.

При этом в SQL запросе ничего такого нет 😀

Странно, что автор не исправил это спустя более чем пол года...

[Yeah]

Это классическая задача для PostGIS, которая решается с использованием функции ST_DWithin

И дальше идёт запрос из второго примера. Идея статьи неплохая, но исполнение на тройку с минусом