Как мы ускорили SQL-запросы: реальные кейсы оптимизации PostgreSQL

Очевидно комментарий человека который не разбирается в теме, но без пруфов пишет что то "ерунда".
Лучше бы предложили свой вариант с вашей реализацией. Пруфы что это ерунда тоже не помешали бы - обоснования в студию с метриками.

Как мы ускорили SQL-запросы: реальные кейсы оптимизации PostgreSQL

Вы можете использовать offset хоть на несколько миллионов строк, если вам не нужно поддерживать огромное кол-во сортировок.

SELECT *
FROM orders
WHERE user_id IN (
    SELECT user_id
    FROM orders
    WHERE %(any_conditions_for_filters)
    ORDER BY created_at DESC
    OFFSET 120
    LIMIT 20;
)
ORDER BY created_at DESC

Мы подразумеваем что user_id - это первичный ключ, либо просто имеет индекс.
В этом случае OFFSET будет почти незаметен. Вы отфильтровываете уже нужные id, которые хранятся в индексной таблице и не заставляете БД вычитывать все строки данных с диска для OFFSET

Я написал кэш для API на Go за 120 строк кода — и PostgreSQL перестал быть узким местом (ускорение в 7 раз)

Все так или иначе в зависимости от объема данных к этому приходят... Не очень понятно кто ваш клиент API.
Вообще, можете пойти дальше и отдавать заголовок Last-Modified, хранить максимально легковесный кэш параллельно (ну, или повесить индекс и дергать БД по max(update_at), если оно того позволяет - это и сам постгрес закэширует на отлично).

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

Если ваш клиент другой сервис... ну, мало кто это делает, но было бы не плохо написать и там немного кода, чтобы добавить заголовок с меткой времени.

Vite 8.0: долгожданный Rolldown

да, он быстрее, но не все правила eslint перенесены, есть конфликтующие правила между встроенными plugins и уровнями categories в конфиге. Не по всем правилам он пока умеет делать автофиксы, но детектит, не все особенности например vue (кому это важно) поддерживает и т.п.
В общем, я бы на вашем месте относился бы с большим вниманием к попытке перейти на oxc сейчас с eslint, чем просто апнуть на vite@8
Но локально на "домашнем" коде пробую, поднастраиваю под себя конфиги - скорость конечно радует.

Айтишники, что с работой?

У меня какое-то дежавю.
В ноябре уволился вот с такой галеры, где на 3х разрабах сидит по 10 менеджеров - а тем и выгодно что разрабов нет - они что ли код писать будут? можно и подремать..

Embedded SQL с группировкой запросов: элегантный подход к управлению SQL в Go

Ммм... как будто бы напрашивается идея с тем, чтобы DBA вели просто свой "пакет"/репозиторий с набором таких вот *.sql файлов, который подтягивать в нужное место через обертку в виде go.mod или сабмодулем.
На вскидку звучит интересно...
В конце концов существуют же кошмарные репозитории гугла с адовыми обертками для go и остальных :))
Ну что то типа такого https://github.com/google/brotli - кажется идея с аналогичной репой для sql звучит не так ужасно :)))

Embedded SQL с группировкой запросов: элегантный подход к управлению SQL в Go

Делал похожим образом в одном специфичном внутреннем проекте, только использовал text/template т.к. нужно было хитро подставлять значения, или другие кусочки sql.
Оно существовало (и вроде как существует) как проект переноса легаси с питона.
Опять же, получается +- чище, в git удобнее отслеживать изменения, если затрагивались именно SQL запросы, ну и прочие полезные фишки типа прокидывания функций в template и т.д и т.п.
Примерно так выглядел какой нибудь маленький кусочек из множества

SELECT DISTINCT
    CADNUM_PARENT
FROM
    unio.T_HISTORICITY_LINK
WHERE
    CADNUM_PARENT != ANY( {{ joinedArgs `Cads` .Cads }} )
    AND CADNUM_CHILD = ANY( {{ joinedArgs `Cads` .Cads }} )
    AND CADNUM_CHILD != :cad_in
    AND CADNUM_PARENT != :cad_in

Новый фронтенд-фреймворк?

Так вроде есть Lit уже, может даже не он один.
Я конечно не против, пусть выживет сильнейший, но в чем фича?

Давайте сделаем крупное приложение на Flask (язык Python)

Аж глаз радуется.
Бегло пробежал глазами, но это в любом случае идет в закладки, чтобы удобно кидать падаванам как заметку.

Я правда отказался от gunicorn в пользу uWSGI, но это слишком спцифичный кейс когда тредпулы используются внутри хэндлера фласка :))

Nvidia переходит на модули ядра графического процессора с открытым исходным кодом

В проприетарный части просто есть некоторые специфичные компоненты, вроде openCL https://amdgpu-install.readthedocs.io/en/latest/install-script.html#scenarios

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

Соответственно в случае AMD достаточно использовать свежие ядра стабильной ветки.
Если вы точно знаете зачем вам нужен openCL или вариации кодеков AMD (amf), то да, вам придется ставить проприетарный драйвер.

Релиз Linux 6.9

Короче оказалось, что по какой-то причине freesync в прошлых версиях был включен по умолчанию в ядре (как я понял, иначе объяснения нет).

В итоге вернул все частоты включив параметр:

amdgpu.freesync_video=1

Go и pgx. Пагинация в запросах к БД Postgres

Я же написал, просто используйте индексы на те поля которые вам нужны. Индексы хранятся в отдельной таблицы и со своей магией, все что вам нужно от этого джойна - это получить id, а все остальные данные вы получаете уже "наверху".
Вы можете обернуть это ещё раз в под запрос и присоединить что то ещё - это все равно будет быстро, т.к. у вас уже будет ограниченный список выборки.
И да, джойн тут играет магическую роль, не знаю почему, но планировщик мне показывал бОльшую эффективность, чем с where. Но тут не ручаюсь, стоит 15 версия если что.

Конечно, есть крайний случай, когда у вас фильтр подразумевается по всем полям выводимых данных. Ну, тут уже сами прикидывайте что вам важнее, скорость или место на диске/памяти.

Go и pgx. Пагинация в запросах к БД Postgres

Да, именно так, спасибо что сократили мою мысль )))

Короче говоря, перепробовав разные варианты, если вам нужна фильтрация и ограничение выдачи, то более оптимального варианта я не нашел.

Go и pgx. Пагинация в запросах к БД Postgres

https://stackoverflow.com/a/27169302
https://dba.stackexchange.com/a/205286

Простите, но слишком лень гуглить более техническое описание того, почему чистый оффсет такой тяжелый.
СОВСЕМ ПРИМИТИВНОЕ ОБЪЯСНЕНИЕ: если мы применяем оффсет на что-то, что в конечном итоге использует только индексы (в данном случае возвращается только таблица с полем id), то pg не нужно заглядывать целиком в реальную таблицу с данными, читать байтики там чтобы не ошибиться с оффсетом, попутно проверяю условия и т.д. Т.к. мы используем чистое индексное поле на выходе, то pg может на много быстрее посчитать оффсет. По сути мы упираемся только в то, сколько условных байт нам надо прочитать, чтобы корректно отсчитать строки оффсета. ЭТО ОЧЕНЬ ПРИМИТИВНОЕ ОБЪЯСНЕНИЕ! Возможно тут появится гуру pg и объяснит более корректно.

Go и pgx. Пагинация в запросах к БД Postgres

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

Где-то когда-то нашел в комментариях решение, которое на удивление дает около константное время запроса на любую страницу. Концепция простая:

SELECT * FROM mega_table AS m0
INNER JOIN (
    SELECT id FROM mega_table
    WHERE <conditions>
    ORDER BY <conditions>
    LIMIT <i>
    OFFSET <j>
) AS fast_filter ON m0.id = fast_filter.id
<conditions if need>

Суть заключается в том, чтобы избежать некоторых тяжелых операции, если делаете и оффсет и условия и сортировку на одной таблице. Ну и главное, чтобы на поле id из примера был повешен индекс, а так же на те поля по которым вы подразумеваете фильтрацию и сортировку.
Хак в том, чтобы использовать только индексные поля, тем самым не заставляя БД тащить тяжелые тосты и вот это всё, а уже в самом конце, когда нам известны id выборки, то их сильно проще забрать, чем перечитывать страницы для оффсета еще и с сортировкой и условиями.

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

Почти все, что вы хотели бы знать про Docker

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

1. У нас имеется образ с компилятором golang (это может быть любой образ, может вы собираете ffmpeg, там огромное количество всего вам понадобится). Этот образ, условно, пусть будет весить 600мб

2. Компилируем бинарник (если это будет ffmpeg, то например компилируете его в один статичный бинарник, пусть на выходе это будет около 50мб)

3. За конечный образ берете например alpine, т.к. у вас нет никакой линковки, то бинарник будет просто запускаться. Итог: конечный готовый образ у вас будет 60мб (условно), т.е. 50мб ffmpeg + OS alpine.

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

Когда проснулся и узнал, что существуют PWA

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

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

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

Вызов функций Go из Python с помощью ctypes

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

В работе Telegram произошел глобальный сбой, после почти двухчасового простоя сервис заработал снова

В прошлые падения при недоступности например в РФ обычный sock5 помогал. Мы же не знаем до сих пор что там было.

В работе Telegram произошел глобальный сбой, после почти двухчасового простоя сервис заработал снова

Не работает ни через США, ни через Европу. Что то у них серьезно накрылось.