Покажу и свое решение задачи про параметры. Оно использует рекурсивный запрос и JSON для отслеживания текущего состояния параметров (есть удобные операции - и || для удаления и добавления ключа в объект, получается имитация множества).
WITH RECURSIVE enumerated AS (
SELECT *, row_number() OVER (ORDER BY ts) n FROM params
), r(ts, n, params) AS (
SELECT null::timestamp, 0::bigint, '{}'::jsonb
UNION ALL
SELECT p.ts, p.n,
CASE
WHEN p.value IS NULL THEN r.params - p.parameter_name
ELSE r.params || jsonb_build_object(p.parameter_name, 1)
END
FROM r, enumerated p
WHERE p.n = r.n + 1
), lens AS (
SELECT ts, n, array_length(array_agg(keys),1) len
FROM r, jsonb_object_keys(params) keys
GROUP BY ts, n
), intervals AS (
SELECT tsrange(ts, lead(ts) OVER (ORDER BY ts)) tsr, max(len) mlen
FROM lens
GROUP BY ts
)
SELECT lower(tsmr), upper(tsmr), mlen
FROM (
SELECT unnest(range_agg(tsr)) tsmr, mlen
FROM intervals
WHERE mlen = (SELECT max(mlen) FROM intervals) AND mlen > 1
GROUP BY mlen
);
Не, это by design, а не current implementation. Сохраняет первую строку, первая строка определяется по правилам `ORDER BY`, а если это предложение не указано, но ССЗБ. И пример там дальше приведен совершенно однозначный.
SELECT DISTINCT ON ( выражение [, ...] ) сохраняет только первую строку из каждого набора строк, для которого данное выражение даёт одинаковые значения. Выражения DISTINCT ON обрабатываются по тем же правилам, что и выражения ORDER BY (см. выше). Заметьте, что «первая строка» каждого набора непредсказуема, если только не применяется предложение ORDER BY, определяющее, какие строки должны быть первыми.
Чего далеко ходить, вон разработчики хабраредактора отказались от простого текста в пользу не пойми чего с внутренней структурой. Казалось бы, что может пойти не так?
Если нам надо дождаться освобождения строки, фактически мы должны дождаться окончания блокирующей транзакции — все блокировки снимаются при фиксации или откате. А для этого можно запросить блокировку номера блокирующей транзакции (которая, напомню, удерживается самой транзакцией в исключительном режиме). Таким образом число используемых блокировок пропорционально числу одновременно работающих процессов, а не количеству изменяемых строк.
После того как вторая транзакция "упрется" в первую заблокированную строку, она уже не продвинется дальше, пока блокировка номера первой транзакции не будет снята.
Справедливости ради. Строчки — это, конечно, нехорошо, надо было строки, но никак не записи. И колонки в литературе встречаются наравне со столбцами.
Записи и поля — это уже нечто не реляционное, обычно в языках программирования. К тому же поле относится к отдельной записи, а вот в качестве ключа в таблице выступают именно столбцы/колонки.
В 90х годах на коротких маршрутах она могла достигать 15 килограмм, а на длинных и все 30! Такой большой объем документации приводит к дополнительному расходу топлива, ...
И ведь не поспоришь!
... занимает лишнее место в кабине и пассажирском салоне, расходует огромное количество бумаги, что сильно вредит экологии и занимает много времени для её систематизации и изучения как кабинным экипажем, так и различными службами.
Интересно, что такое в вашем представлении кабинный экипаж.
Всегда пожалуйста! Расскажите, Никита, как пришла в голову такая идея и главное — как удалось это отладить? Я долго разбирался (:
Тут, увы, все смешано. Например, колоночное и построчное хранение — тоже перпендикулярная к SQL характеристика.
Красиво!
Да, но если заменить 5 и 3 на другие числа, может получиться уже не так привлекательно (:
Покажу и свое решение задачи про параметры. Оно использует рекурсивный запрос и JSON для отслеживания текущего состояния параметров (есть удобные операции
-и||для удаления и добавления ключа в объект, получается имитация множества).Не, это by design, а не current implementation. Сохраняет первую строку, первая строка определяется по правилам `ORDER BY`, а если это предложение не указано, но ССЗБ. И пример там дальше приведен совершенно однозначный.
https://postgrespro.ru/docs/postgresql/17/sql-select#SQL-DISTINCT
Об этом речь?
Чего далеко ходить, вон разработчики хабраредактора отказались от простого текста в пользу не пойми чего с внутренней структурой. Казалось бы, что может пойти не так?
Вот ключевой фрагмент:
После того как вторая транзакция "упрется" в первую заблокированную строку, она уже не продвинется дальше, пока блокировка номера первой транзакции не будет снята.
Все так.
Справедливости ради. Строчки — это, конечно, нехорошо, надо было строки, но никак не записи. И колонки в литературе встречаются наравне со столбцами.
Записи и поля — это уже нечто не реляционное, обычно в языках программирования. К тому же поле относится к отдельной записи, а вот в качестве ключа в таблице выступают именно столбцы/колонки.
Истинная правда. Но
в Постгресе как раз индексируются.
С помощью госуслуг бюрократию отлично автоматизировали, но побеждать ее и в мыслях ни у кого нет.
Нет, просто не развивается. По большому счету это прототип, который по-хорошему надо переосмыслить и переделать, но пока ни у кого не дошли руки.
Возможно, аккаунт удалился? Не знаю.
Вы же говорите про массивы, json-ы, документы. Какие там записи, какие поля? И с какой радости индекс обновляется целиком?
Это как вообще? И какого волнует производительность на малых объемах?
Хранит список значений, содержащихся в колонке? Как вы себе это представляете? А btree не хранит?
А не по умолчанию поддерживает? И что вообще такое эффективный запрос сортировки?
В общем, зря вы это. Лучше сначала разобраться в вопросе, а потом уже писать.
И ведь не поспоришь!
Интересно, что такое в вашем представлении кабинный экипаж.
О, фон перекрасили, молодцы. https://habr.com/ru/posts/899492/
Сама-то статья примерно никакая, но в первом комментарии Олег Бартунов оставил там ссылку на достоверную информацию.
Вы только не переживайте так. Ну неправильный слон, ну что делать. Но лучше ж, чем нейронкой картинки генерить.