LINUX.ORG.RU

PostgreSQL 18

 , ,


0

4

25 сентября, после более года разработки, состоялся выпуск стабильной версии 18 свободной объектно-реляционной системы управления базами данных PostgreSQL.

PostgreSQL 18 повышает производительность для рабочих нагрузок любого масштаба благодаря новой подсистеме ввода-вывода, которая показала до 3× ускорение чтения из хранилища, а также увеличивает число запросов, которые могут использовать индексы. Этот релиз делает обновления мажорной версии менее разрушительными, ускоряет сам процесс обновления и сокращает время, необходимое, чтобы после обновления выйти на ожидаемую производительность. Разработчики также выигрывают от функций PostgreSQL 18 — например, виртуальных вычисляемых столбцов, которые рассчитывают значения во время выполнения запроса, и дружественной к СУБД функции uuidv7(), обеспечивающей более быстрые индексацию и чтение UUID. Кроме того, PostgreSQL 18 упрощает интеграцию с системами единого входа (SSO) благодаря поддержке аутентификации OAuth 2.0.

«Усилия глобального сообщества разработчиков ПО с открытым исходным кодом формируют каждый релиз PostgreSQL и помогают предоставлять функции, отвечающие потребностям пользователей там, где находятся их данные, — сказал Джонатан Кац (Jonathan Katz), член основной команды PostgreSQL. — PostgreSQL 18 опирается на долгую и богатую историю проекта по предоставлению надежного и эффективного управления данными, при этом продолжая расширять спектр поддерживаемых рабочих нагрузок.»

PostgreSQL — инновационная система управления данными, известная своей надёжностью, устойчивостью и расширяемостью. Она развивается уже почти 30 лет в рамках открытого сообщества разработчиков и стала предпочтительной реляционной СУБД с открытым исходным кодом для организаций любого размера.

Основные изменения:

  • Появление асинхронного ввода-вывода (AIO)
    • Ранее для ускорения доступа к данным PostgreSQL полагался на механизм опережающего чтения (readahead) операционной системы. Однако, поскольку операционные системы не понимают специфичных для баз данных паттернах доступа, они не всегда могут предсказать, какие данные потребуются, что приводит к неоптимальной производительности во многих рабочих нагрузках.
    • PostgreSQL 18 внедряет новую подсистему асинхронного ввода-вывода (AIO), разработанную для устранения этого ограничения. AIO позволяет PostgreSQL отправлять несколько запросов ввода-вывода (I/O) параллельно, не дожидаясь последовательного завершения каждого. Это дополняет существующий readahead и улучшает общую пропускную способность. В PostgreSQL 18 поддерживаются операции AIO для последовательных сканирований, сканирований по битовой карте (bitmap) страниц кучи (heap) и вакуума. Сравнительное тестирование продемонстрировало прирост производительности до 3 раз в некоторых сценариях.
    • Новый параметр io_method позволяет выбирать между реализациями AIO, включая worker и io_uring, либо сохранить текущее поведение PostgreSQL с настройкой sync. При включении AIO появляется больше параметров, доступных для тонкой настройки — подробнее в документации.
  • Более быстрые обновления и улучшенная производительность после обновления
    • Ключевая особенность PostgreSQL — сбор и хранение статистики, которая помогает планировщику выбирать наиболее эффективный план запроса. До PostgreSQL 18 эта статистика не переносилась между экземплярами при обновлении мажорной версии, что могло вызывать заметную деградацию производительности запросов на нагруженных системах до завершения выполнения операции ANALYZE. В PostgreSQL 18 появилась возможность сохранять статистику планировщика при обновлении мажорной версии, что позволяет обновлённому кластеру быстрее выйти на ожидаемую производительность.
    • Кроме того, утилита pg_upgrade, предназначенная для обновления между мажорными версиями, получила ряд улучшений в PostgreSQL 18, включая более быстрые обновления, когда в базе много объектов, таких как таблицы и последовательности. Этот выпуск также позволяет pg_upgrade обрабатывать свои проверки параллельно в зависимости от настроек флага --jobs и добавляет флаг --swap, позволяющий менять местами каталоги обновления вместо копирования, клонирования или связывания файлов.
  • Улучшения производительности запросов и общие оптимизации
    • PostgreSQL 18 дополнительно повышает производительность запросов благодаря функциям, которые автоматически ускоряют выполнение рабочих нагрузок. В этом выпуске представлены функции поиска «skip scan» по многоколоночным индексам B-дерево, улучшающие время выполнения запросов, в которых отсутствует условие = для одной или нескольких первых колонок индекса. Также оптимизируются запросы с условиями OR в WHERE, позволяя использовать индекс и существенно сокращая время выполнения. Также внесены многочисленные улучшения в планирование и выполнение соединений таблиц PostgreSQL: от ускорения хеш-соединений (hash join) до возможности использования инкрементальных сортировок в соединениях слиянием (merge join). PostgreSQL 18 также поддерживает параллельное создание GIN-индексов, дополнив этим B-деревья и BRIN-индексы, которые уже поддерживали такую возможность.
    • Релиз также развивает поддержку аппаратного ускорения: добавлены инструкции ARM NEON и SVE центрального процессора для встроенной функции popcount, которую использует bit_count и другие внутренние механизмы.
  • Улучшение опыта разработчика
    • PostgreSQL 18 вводит виртуальные вычисляемые столбцы, значения которых вычисляются во время выполнения запроса вместо хранения на диске (это теперь поведение по умолчанию для вычисляемых столбцов). Кроме того, «хранимые» вычисляемые столбцы теперь поддерживаются в логической репликации.
    • В этой версии появилась возможность получать как прежние (OLD), так и текущие (NEW) значения в предложении RETURNING для команд INSERT, UPDATE, DELETE и MERGE. PostgreSQL 18 также добавляет генерацию UUIDv7 с помощью функции uuidv7(), позволяя создавать случайные UUID, упорядоченные по временной метке, что улучшает стратегии кэширования. Кроме того, в PostgreSQL 18 функция uuidv4() добавлена как псевдоним gen_random_uuid().
    • PostgreSQL 18 добавляет временные ограничения — ограничения по диапазонам — для PRIMARY KEY и UNIQUE с использованием конструкции WITHOUT OVERLAPS, а также для FOREIGN KEY с использованием PERIOD.
    • Наконец, стало проще создавать схему внешней таблицы на основе локальной: добавлена команда CREATE FOREIGN TABLE … LIKE.
  • Улучшенная обработка текста
    • PostgreSQL 18 упрощает и ускоряет работу со строками благодаря нескольким улучшениям. В этом выпуске добавлена сортировка PG_UNICODE_FAST, которая обеспечивает полноценную семантику Unicode для преобразования регистра, помогая ускорить многие сравнения. Это касается функций upper и lower, а также новой функции casefold для регистронезависимых сравнений. Кроме того, PostgreSQL 18 теперь поддерживает выполнение сравнений LIKE над текстом с недетерминированной сортировкой, что упрощает сложный поиск по шаблону. В этом релизе также изменено поведение полнотекстового поиска: теперь он использует поставщика сортировки по умолчанию для кластера вместо принудительного использования libc. Это может потребовать пересоздания всех индексов полнотекстового поиска и pg_trgm после выполнения pg_upgrade.
  • Аутентификация и безопасность
    • PostgreSQL 18 добавляет аутентификацию oauth, позволяющую пользователям проходить проверку подлинности с использованием механизмов OAuth 2.0, поддерживаемых через расширения PostgreSQL. Кроме того, PostgreSQL 18 добавляет проверку режима FIPS и новый параметр ssl_tls13_ciphers для настройки наборов шифров TLS v1.3 на стороне сервера.
    • В этом выпуске прекращена поддержка аутентификации по паролю md5 (будет удалена в одном из будущих релизов). Если вам требуется парольная аутентификация в PostgreSQL, используйте SCRAM-аутентификацию. PostgreSQL 18 также поддерживает сквозную аутентификацию SCRAM с помощью postgres_fdw и dblink для аутентификации на удалённых экземплярах PostgreSQL. Кроме того, pgcrypto теперь поддерживает шифрование паролей с использованием SHA-2.
  • Репликация
    • PostgreSQL 18 поддерживает регистрацию конфликтов записи при логической репликации в журналах и в представлении pg_stat_subscription_stats. Кроме того, теперь команда CREATE SUBSCRIPTION по умолчанию применяет транзакции в несколько параллельных потоков, что может повысить производительность. Утилита pg_createsubscriber получила флаг --all, позволяющий создавать логические реплики для всех баз данных в экземпляре одной командой. Также PostgreSQL 18 позволяет автоматически удалять неактивные слоты репликации, чтобы избежать избыточного накопления файлов журнала предзаписи (WAL) на стороне публикующего сервера.
  • Обслуживание и наблюдаемость
    • PostgreSQL 18 улучшает стратегию очистки, путём упреждающей заморозки большего количества страниц во время регулярной очистки, что снижает накладные расходы и помогает в ситуациях, требующих агрессивной очистки.
    • PostgreSQL 18 добавляет больше информации в EXPLAIN, который предоставляет информацию о выполнении плана запроса, и, начиная с этого выпуска, теперь автоматически показывает, сколько буферов (основной единицы хранения данных) используется при выполнении EXPLAIN ANALYZE. Кроме того, EXPLAIN ANALYZE показывает количество обращений к индексу при его сканировании, а EXPLAIN ANALYZE VERBOSE включает статистику использования процессора, WAL и средним временам чтения. В представлении pg_stat_all_tables появилась дополнительная информация о времени, затраченном на очистку и связанные с ней операции, а также статистику ввода-вывода и использования WAL по каждому соединению.
  • Прочие заметные изменения
    • Базы данных, инициализированные с помощью initdb в PostgreSQL 18, теперь по умолчанию создаются с включёнными контрольными суммами страниц. Это может повлиять на обновления с кластеров, где контрольные суммы выключены: при использовании pg_upgrade для обновления таких кластеров потребуется создать новый кластер PostgreSQL 18 с опцией --no-data-checksums.
    • Кроме того, PostgreSQL 18 представляет новую версию (3.2) протокола взаимодействия (wire protocol) PostgreSQL — первое обновление протокола с момента выхода PostgreSQL 7.4 (2003 год). При этом libpq по умолчанию по-прежнему использует версию 3.0, пока клиенты (например, драйверы, пулеры, прокси) не добавят поддержку новой версии протокола.
  • Дополнительные возможности
    • Множество других новых функций и улучшений также вошли в PostgreSQL 18 и могут оказаться полезными для ваших сценариев. Полный список новых и изменённых возможностей приведён в примечаниях к релизу.

>>> Подробности на postgresql.org

★★★★★

Проверено: Dimez ()
Ответ на: комментарий от borisych

в твиторе используется некий Snowflake Id, всего-то 64 бита - им хватает вполне, но для лоровских экспертов 64 бита на индентификатор - это крайне мало, нужно больше (угу, у каждого второго под кроватью не пыль, а 10 твиторов)

Да это жесть. Ютубный жалкий 64-битный рандомный ID распределённо генерируется и позволяет каждому микробу заливать сто миллиардов нанотыщ видосов в килосекунду и всё никак не кончается!

lesopilorama
()
Ответ на: комментарий от borisych

Никто же не говорит, что без UUIDv7 все сервисы работали в 10 раз медленней, чем могли бы. На синтетических тестах преимущества велики. В реальной жизни база будет тормозить из-за того, что индекса вообще нет, а не из-за того, что индекс на 22% больше.

Но это не значит, что нужно отметать более оптимальный подход без причин.

не будет там конкуренции за расщепление блоков индекса?

Какая бы ни была конкуренция, скорость записи на диск это главный фактор. Если 10 потоков записывают по 10 строк, лучше они будут это делать в конец индекса, пусть и по очереди, это будет быстрей, чем если они будут делать это одновременно в разные части индекса.

vbr ★★★★★
()
Ответ на: комментарий от thriller

Всё, что можно сэкономить вычислительно на «парсинге», тут же с лихвой съедается обратно затратами на сериализацию, когда надо сбоку нарисовать кучу ссылок с рекомендуемыми роликами.

64 бита уже давно можно прислать прямо в браузер по бинарному вебсокету или бинарному чему угодно и пусть браузер ссылки рендерит как хочет.

lesopilorama
()
Ответ на: комментарий от MaZy

На самом деле это все манипулирование и чушь, основанные на ложных посылах. Причем практически по всем пунктам.

Какая альтернатива? Альернатива - самостоятельная разработка системы хранения данных. И вот тут начинается самое интересное. Сначала ты разрабатываешь простейшее и все работает. Но работает криво, ибо нужно чуть чуть больше учесть, доработать, доделать. И ты доделываешь, допиливаешь, усложняешь.

На разработку своей системы ты потратишь гораздо больше времени и усилий, что приведет тебя в итоге….к СУБД. К тому же, что уже готово и стандартизированно. Но у тебя нет таких знаний и опыта, как у специализированных разработчиков, так что у тебя это будет еще и багованно и неоптимально. И в итоге жрать будет даже больше, а работать кривее.

И этим будут заниматься все. То есть каждый вместо нормальной работы будет делать одну и ту же задачу повторно самостоятельно.

Тот пост про СУБД - явная психологическая диверсия.

Я как раз три года пилю свой проект и свою систему хранения данных, все это вижу на практике. Пока на СУБД не перешел, но это очень хорошая мысль, очень даже стоит попробовать.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

И этим будут заниматься все. То есть каждый вместо нормальной работы будет делать одну и ту же задачу повторно самостоятельно.

Ну и хорошо. Все заняты интересным делом (:

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

Какая бы ни была конкуренция, скорость записи на диск это главный фактор. Если 10 потоков записывают по 10 строк, лучше они будут это делать в конец индекса, пусть и по очереди, это будет быстрей, чем если они будут делать это одновременно в разные части индекса.

проведите эксперимент для начала. Я утверждаю, что монотонный индекс на многопоточной вставке - это полная жопа (почитайте, к примеру, откуда в Oracle появился reverse index), однако, уровень экспертизы в среде PostgreSQL довольно посредственный, и отсюда возникают ситуации, что куча народу радуется, что кто-то закоммитил 10 ссаных строчек в проект, но при этом эта замечательная СУБД все также продолжает кешировать одни и те же данные дважды - прекрасное достижение за 25 лет на мой взгляд.

borisych ★★★★★
()
Ответ на: комментарий от vbr

Хренасе ты быстро читаешь. Меньше минуты на все. И ведь вчитался же. Это впечатляет, серьезно.

Проблема в том, что делом можно быть занятым нормальным, а не тем, что уже есть. То есть лучше разрабатывать свою уникальную программу, а не переделывать существующее в 100500 раз.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Проблема в том, что делом можно быть занятым нормальным, а не тем, что уже есть. То есть лучше разрабатывать свою уникальную программу, а не переделывать существующее в 100500 раз.

Тут смотря с какого уровня абстракции смотреть. Я вроде в каждом проекте разрабатываю уникальную программу, а вроде и данные из JSON/XML в SQL перекладываю уже 15 лет не переставая. Для хозяина фирмы проект уникальный, а я это всё видел уже 10 раз, отличаются только названия столбцов.

vbr ★★★★★
()
Ответ на: комментарий от vbr

Ужасный, неоптимальный формат.

Чувак base64 назвал неоптимальным, а лучше ничего не предложил. Аргументы поражают конечно.

lesopilorama
()
Ответ на: комментарий от vbr

А все программирование на 99% в этом и заключается - в перекладывании данных. Архитекура компов такая.

Мне поэтому в целом бэкенд и нравится - это же основа.

LightDiver ★★★★★
()
Ответ на: комментарий от ivanich10

Это который падает постоянно и для поднятия которого надо вызывать СЕРТИФИЦИРОВАННОГО СПЕЦИАЛИСТА, который магическими командами его поднимает? Надеюсь, никогда до такого уровня постгрес не дойдёт.

PS недавно всплыл мой старый проект, там постгрес 9.6 на windows server 2003. Где-то 12 лет назад я его сделал, настроил, он так и работает до сих пор. Красота.

vbr ★★★★★
()
Ответ на: комментарий от LightDiver

Какая альтернатива? Альернатива - самостоятельная разработка системы хранения данных. И вот тут начинается самое интересное.

Да заканчивайте вы комментировать высеры шизанутого Столярова, там же жирное тролление 80 левела, вы чё как эти. Вы ещё бы поспорили о том, что лучше - коммунизм или капитализм тут. Столяров - это дурка, он не профессионал, он книжки пишет и преподаёт как раз потому, что на работку денежную никуда не взяли.

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 3)
Ответ на: комментарий от lesopilorama

Так я же тебе показал кучу символов, которую можно было бы добавить в алфавит и кодировать оптимальней.

vbr ★★★★★
()
Ответ на: комментарий от lesopilorama

64 бита уже давно можно прислать прямо в браузер по бинарному вебсокету или бинарному чему угодно и пусть браузер ссылки рендерит как хочет.

И мы ещё потом удивляемся, почему простые статичные страницы в современном вебе жрут память сотнями мегабайт…

thriller ★★
()
Ответ на: комментарий от lesopilorama

Ну, это интересный взгляд на вещи. Даже если с ложным посылом, иногда стоит задуматься и пересмотреть приоритеты.

А перетряхнуть сообщество может только человек такого уровня.

LightDiver ★★★★★
()
Ответ на: комментарий от vbr

Так я же тебе показал кучу символов, которую можно было бы добавить в алфавит и кодировать оптимальней.

Так они урл тебе ломают же.

lesopilorama
()
Ответ на: комментарий от borisych

Уже понятно, что вы - фанат Oracle. Но PostgreSQL - не просит ни у кого денег, любой может внести улучшения.

С Oracle их даже сравнивать смешно. Oracle - стоит настолько безумных денег, что почти невозможно найти инсталляции. С дикой ценой за каждое ядро каждой установки, их может позволить себе только организация, печатающая деньги.

Плюс, как показал 22-й год, даже несмотря на то, что какие-то организации, расставались с этими астрономическими суммами, Oracle может в одно мгновение их кинуть, растворившись с деньгами и невыполненными обязательствами.

Как минимум, только поэтому, PostgreSQL уже лучше. Хотя это и не технический аргумент.

Что касается экспертизы разработчиков PostgreSQL, то, полагаю, она намного выше, чем у практически любого завсегдатая ЛОРа. И если они что-то не делают, то, возможно, не потому что не понимают преимуществ, а потому что, например, не хватает рук реализовать.

Chiffchaff
()
Ответ на: комментарий от LightDiver

Ну, это интересный взгляд на вещи.

Да он не интересный, он обоссан уже сто раз и боян.

А перетряхнуть сообщество может только человек такого уровня.

Какого ещё уровня, он же просто п**дит, а мешки ворочать не пробовал.

lesopilorama
()
Ответ на: комментарий от vbr

Аххахаха) Я тут сам с нуля изобрел base85 еще до того, как узнал о существовании base64 и base85. Я сам прошел этот путь, нихрена не зная, потом увидел как это уже было реализовано, варианты. Потом увидел как реализованы СУБД.

И про алфавит тоже были такие же мысли по оптимизации, к слову. Даже ностальгия.

LightDiver ★★★★★
()
Ответ на: комментарий от Chiffchaff

любой может внести улучшения.

Это такая опенсурсная байка. Там шизанёшься, пока изменения внесёшь - пока пройдёшь все этапы ревью и всё наконец примут, выйдет уже новая мажорная версия постгреса и тебе скажут «вали ребейзить уже». Чтобы туда что-то нормально вносить, надо прямо специализироваться на этой штуке фуллтайм и желательно работать в каком-то Postgres PRO за деньги и тут мы получаем, что ты стал ораклом.

lesopilorama
()
Ответ на: комментарий от lesopilorama

Это как раз понятно. Но хотя бы чисто техническая возможность существует. И именно благодаря этой возможности Postgres стала тем, чем стала. Потому что в своё время кто-то не ленился и вносил изменения бесплатно.

Chiffchaff
()
Ответ на: комментарий от lesopilorama

Так они урл тебе ломают же.

Что значит «ломают»? Все эти символы разрешены в URL. Запрос на сервер уходит. Сервер его может интерпретировать как ему надо, ничего этому не препятствует.

1 % openssl s_client -connect youtube.com:443
Connecting to 172.217.21.174
CONNECTED(00000003)
...
Verify return code: 0 (ok)
---
GET /^,.-!/()=?*;:_{}[]\|~` HTTP/1.0

---
Post-Handshake New Session Ticket arrived:
SSL-Session:
...
---
read R BLOCK
HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
Content-Length: 1572
Date: Wed, 01 Oct 2025 08:38:20 GMT
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

<!DOCTYPE html>
...

Вот я у ютуба запрашиваю URL со всеми этими символами и всё прекрасно работает.

vbr ★★★★★
()
Ответ на: комментарий от LightDiver

Понимаешь, если такое скажем мы с тобой, этого никто не заметит, а его обсуждают неделями все в итоге.

Так ценностью считается не что-то сделать, чем будут пользоваться, а разжечь пуканы в интернетике?

lesopilorama
()
Ответ на: комментарий от LightDiver

Понимаешь, если такое скажем мы с тобой, этого никто не заметит, а его обсуждают неделями все в итоге.

Это общее для всех блоггеров-инфлюэнсеров. Можно быть просто никем, куклой с надутыми частями тела, но если было вложено много ресурсов в раскрутку, то такая тупая кукла будет регулярно появляться в новостях, и каждое слово будет долго обсуждаться.

Например, актёры, певцы и певицы ротом. Эти люди обычно мало что знают за пределами своей профессии, что достаточно очевидно даже после прочтения их интервью. Однако, любое их мнение по политической, экономической, или любой другой теме, тиражируется всеми медиа и обсасывается неделями.

Chiffchaff
()
Ответ на: комментарий от lesopilorama

пока пройдёшь все этапы ревью и всё наконец примут, выйдет уже новая мажорная версия постгреса и тебе скажут «вали ребейзить уже».

вы все врете. там дела обстоят совсем иначе:

  • кто-то в рассылку присылает патч на актуальный срез кода
  • никто полгода этот патч не смотрит, потому что ребята из PostgreSQL заняты тем, чтобы продавать свои собственные сборки и консалтинг
  • где-то через полгода автор патча начинает интересоваться: а как там дела, есть какие-то замечания или нет?
  • в ответ он получает: твоя полугодовая нетленка на текущий код уже не натягивается - иди меняй.
borisych ★★★★★
()
Ответ на: комментарий от lesopilorama

Видимо что то он всетаки сделал, что к нему прислушиваются и его обсуждают? И заметь, в среде программистов, сисадминов - то есть в его профессиональной среде. То есть это не просто громкое имя, но и кое какое дело.

LightDiver ★★★★★
()
Ответ на: комментарий от Chiffchaff

Это как раз понятно. Но хотя бы чисто техническая возможность существует. И именно благодаря этой возможности Postgres стала тем, чем стала. Потому что в своё время кто-то не ленился и вносил изменения бесплатно.

Ну в целом-то да. Но вот изнутри это такое уже древнее болотное сишное поделие с горами макросов, в то время когда C++ давно бороздил просторы и позволял бы написать то же самое короче и понятнее. Проект немного отпугивает своей престарелой заскорузлостью, оправдываемой «работает - не трогай» и молодые умы часто выбирают пойти пилить новую распределённую СУБД с нуля, где можно ещё выразить свои идеи, а не где всё уже сделано и на каждой важной фиче уже сидит толстый эксперт-знаток.

lesopilorama
()
Ответ на: комментарий от Chiffchaff

Ты не учитываешь среди кого он известен. В той публике, в которой популярны певцы ртом, никто не слышал ни разу про него.

LightDiver ★★★★★
()
Ответ на: комментарий от vbr

«Вопрос» ? тебе нужен параметры передавать в урле, & тоже застолблён, и вообще тут тема кратности какая-то, нет смысла делать base65, есть смысл делать base128 сразу, а тут уже не хватает символов. base64 оптимален.

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от Chiffchaff

Уже понятно, что вы - фанат Oracle. Но PostgreSQL - не просит ни у кого денег, любой может внести улучшения.

я уже где-то приводил сравнения, там было показано, что PostgreSQL стоит никак не дороже Oracle. Вот один из примеров: Postgres Pro Shardman: обновление СУБД для крупных предприятий (комментарий), другие лень искать.

borisych ★★★★★
()
Ответ на: комментарий от LightDiver

Видимо что то он всетаки сделал, что к нему прислушиваются и его обсуждают?

Понаплодил книжек. Аффтар он. Преподавал в универе. В общем, на ниве набрасывания на вентилятор смог забраться со своим ртом достаточно высоко и повнедряться туда, где точно будут слушать или читать.

lesopilorama
()
Ответ на: комментарий от qulinxao3

Да, но сложный выбор. Наверное, стоит смотреть на что-нибудь со словом «develop». Обслуживание можно и в доке почитать, а вот как принято решать типовые и нетиповые задачи, где можно упереться в оптимизатор, для каких сценариев лучше подходит определённый механизм, что-то ближе к системному дизайну, эффективной разработке и набитию шишек — это сложно найти. Может быть, конечно, я не там смотрю, но кроме сухой теории в стиле «если хочешь надёжно, то простые задачи станут сложными» хотелось бы примеров, воспроизводимых и приближенных к жизни. The Art of PostgreSQL пытается таким быть, но слишком прост, в стиле «order by может применяться к алиасам и вычисляемым значениям». На оконные функции отведено только 10 страниц.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 4)
Ответ на: комментарий от lesopilorama

Так никто не мешает делать своё, на каком угодно языке. Многие и делают. Вон, YDB, например.

У любого проекта есть жизненный цикл, и на каком-то этапе он обязательно становится «скучным» и «заскорузлым». Но это палка о двух концах.

Когда-то, например, на волне хайпа многие перескочили, не подумав, на MongoDB, и огребли гору проблем.

Chiffchaff
()
Ответ на: комментарий от borisych

Ну да, и так лет по 15 бывает: когда патч пилить начинаешь, надо сразу подыскивать потомков-продолжателей дела, чтобы когда ты в гробу уже будешь лежать смог додиктовать последние фиксы кому-то.

Это такой жестокий пример опенсорса, когда проект заделавшись под опенсорс и добрые либеральные идеи свободы и равенства нагло ворует человекочасы доверчивых лохов. Ты смог, ты молодец, на тебе признание мировое!

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 3)
Ответ на: комментарий от lesopilorama

Нет смысла делать base128. Я начал с 91 символа вообще. Но, понимаешь, современный софт некоторые символы использует как служебные. И потом я сокращал сокращал и пришел к оптимальному base85. Он включает ровно те символы, что нужны и не включает служебные. Да и то не всегда. Я даже подумывал уйти до 84 символов, но это надо еще подумать.

А base64 дает слишком мало уникальных объектов в сравнении с base85. Это же почти в два раза разница: 4096 объектов при двух символах против 7225 объектов.

LightDiver ★★★★★
()
Ответ на: комментарий от lesopilorama

Ну так попробуй наплоди книжек, которые будут читать, преподай в универе, накидай на вентилятор так, чтобы это обсуждали.

Пытаются многие, получается не у всех.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

А base64 дает слишком мало уникальных объектов в сравнении с base85. Это же почти в два раза разница: 4096 объектов при двух символах против 7225 объектов.

Base85 - если сможешь это продать в мире URL, то есть оттуда ничего не законфликтует с HTTP/1.1 и желанием передавать ?param=value&param=value то вперёд, чё. Просто наверное законфликтует.

lesopilorama
()
Ответ на: комментарий от LightDiver

Ну так попробуй наплоди книжек, которые будут читать, преподай в универе, накидай на вентилятор так, чтобы это обсуждали.

Пробовал, доходность от этой возни крайне мала. Это работа на неплатящую аудиторию. Разные рынки: те, кто способен возбудиться с набросов Столярова и заобсуждать его - неплатящая аудитория, с ней связываться не выгодно. Пообсуждают, помолятся и всё. 500 комментов в треде про себя - в карма не положишь, в резюме не укажешь. А профита ноль. Возбуждающиеся с набросов столярова - студенты, всякие там неопытные и фрики. Это не тот рынок, на котором есть деньги.

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от lesopilorama

Ну я работаю с этим в рамках одной игры вне веба вообще, так что хз. Я смотрю со своей колокольни. В рамках моей песочницы оптимальн было бы 84 символа - это тот максимум, который бы ни с чем не конфликтовал.

А base64 в моем случае тоже смысла не имеет - зачем сокращать себе самому рамки, если можно их не сокращать? Если я смогу вместить в 2 символа 7225 объектов, я это сделаю.

LightDiver ★★★★★
()
Ответ на: комментарий от ivanich10

Сколько еще до уровня Oracle, по крайней мере 8 ?

UNDO подрывались сделать (точнее речь шла про разные движки, как в MySQL, и на эту концепцию UNDO вроде как ложилось) где-то лет 6 назад - сдохло-таки, хинтов так и нет, хотя потребность и тупость планировщика уже давно стали очевидными, трансформаций запросов толковой нет. Отставание лет так в 20, никак не меньше.

borisych ★★★★★
()
Ответ на: комментарий от lesopilorama

«Вопрос» ? тебе нужен параметры передавать в урле, & тоже застолблён

Это исключительно соглашений. В HTTP нет никакого особого значения у символов ? и &. То, что сервер их интерпретирует каким-то специальным образом, это только его дело, никто не мешает их интерпретировать как угодно.

и вообще тут тема кратности какая-то, нет смысла делать base65, есть смысл делать base128 сразу, а тут уже не хватает символов. base64 оптимален.

Конечно есть. Если у тебя 64 бита, то в base64 тебе нужно 11 символов, чтобы их закодировать. А если ты берёшь вышеописанный «base85», то у тебя помещается как раз чуть больше 6.4 битов на символ и ты можешь закодировать 64 бита в 10 символов. 1 символ сэкономили. Ура.

vbr ★★★★★
()
Ответ на: комментарий от vbr

Это исключительно соглашений. В HTTP нет никакого особого значения у символов ? и &. То, что сервер их интерпретирует каким-то специальным образом, это только его дело, никто не мешает их интерпретировать как угодно.

Ясно, что соглашений. Но на них согласились уже. А разговоры про base64 vs base85 vs youtube должны быть снабжены исследованиями чуть более глубокими, я не готов, у меня сведений мало, не в курсе в чём будет проблема - в deepseek можно сходить с вопросом наверное. Но любой ссаный base64 точно получше, чем пихать везде UUID с этими тире посередине)

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 3)
Ответ на: комментарий от LightDiver

Просто правда в том, что всем плевать на эти оптимизации. Ну 99.99% проектов. Может ютубу не плевать. Но мы-то не ютубы пишем. У меня вот как-то проблема была - реверс прокси запрос не передавал. Начал разбираться - оказывается запрос вместе со всеми заголовками какой-то там лимит превысил и nginx такое даже парсить отказался. Там в заголовке Cookie какой-то адски длиннющий токен передавался, могу путать, но вроде больше 1000 символов. А мы тут пытаемся 64 бита закодировать оптимальней.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

Не всем и не плевать, но да. Все дело в рамках инфраструктуры.

Плевать ровно до тех пор, пока ты не приходишь к ограничению инфраструктуры. Когда упираешься в ограничения, хочешь ты или нет - нужно оптимизировтаь.

LightDiver ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
Тема будет перемещена в архив .