Forwarded from DLStories
Нашла еще один интересный подход к сегментации изображений: с помощью разбиения графа self-attention карты трансформера.
В чем идея:
Берем vision transformer, обученный на картинках в self-supervised режиме. Т.е. без какой-либо обучающей разметки. Смотрим на карты его self-attention. Оказывается, что на этих картах становтся подсвечены контуры объектов (см. 1 рис). Причем такое наблюдается только для трансформеров, обученных в self-supervised режиме: ни для supervised трансформеров, ни для CNN такое не работает.
Одними из первых это свойство заметили ребята из FAIR (статья). Они пошли дальше: взяли эти self-attention карты, обучили на них KNN и получили качество 78.3% top-1 на ImageNet.
Но вернемся к сегментации. Другие ребята придумали, как сделать сегментацию на основе этого свойства. Идея простая: берем элементы self-attention карты трансформера и строим на них граф. Ребро между двумя векторами будет равно 1, если косинусное расстояние между ними больше заданного порога, и eps, если меньше порога. На таким графе решаем задачу разбиения графа (normalized cut). Так элементы карты аттеншена, соответствующие объекту, будут отделены от элементов, соответствующих фону.
Последний шаг — применяем какой-нибудь алгоритм edge refinement (например, стандартный CRF), и получаем неплохую карту сегментации объекта на картинке.
Недостаток такого подхода — он умеет сегментировать только один объект на картинку. Поэтому ребята из FAIR (уже другие) предложили, как улучшить идею. Все просто: находим карту одного объекта. Далее накладываем на патчи self-аттэншена этого объекта маску, и снова запускаем алгоритм. И так несколько раз.
Это позволяет находить на одной картинке сразу несколько объектов (рис. 2).
Вот такая идея. Вообще, attention maps разных трансформеров часто обладают подобными свойствами, и на основе информации из них можно понимать, как "думает" моделька и решать разные downstream задачи. Интересно их исследовать)
В чем идея:
Берем vision transformer, обученный на картинках в self-supervised режиме. Т.е. без какой-либо обучающей разметки. Смотрим на карты его self-attention. Оказывается, что на этих картах становтся подсвечены контуры объектов (см. 1 рис). Причем такое наблюдается только для трансформеров, обученных в self-supervised режиме: ни для supervised трансформеров, ни для CNN такое не работает.
Одними из первых это свойство заметили ребята из FAIR (статья). Они пошли дальше: взяли эти self-attention карты, обучили на них KNN и получили качество 78.3% top-1 на ImageNet.
Но вернемся к сегментации. Другие ребята придумали, как сделать сегментацию на основе этого свойства. Идея простая: берем элементы self-attention карты трансформера и строим на них граф. Ребро между двумя векторами будет равно 1, если косинусное расстояние между ними больше заданного порога, и eps, если меньше порога. На таким графе решаем задачу разбиения графа (normalized cut). Так элементы карты аттеншена, соответствующие объекту, будут отделены от элементов, соответствующих фону.
Последний шаг — применяем какой-нибудь алгоритм edge refinement (например, стандартный CRF), и получаем неплохую карту сегментации объекта на картинке.
Недостаток такого подхода — он умеет сегментировать только один объект на картинку. Поэтому ребята из FAIR (уже другие) предложили, как улучшить идею. Все просто: находим карту одного объекта. Далее накладываем на патчи self-аттэншена этого объекта маску, и снова запускаем алгоритм. И так несколько раз.
Это позволяет находить на одной картинке сразу несколько объектов (рис. 2).
Вот такая идея. Вообще, attention maps разных трансформеров часто обладают подобными свойствами, и на основе информации из них можно понимать, как "думает" моделька и решать разные downstream задачи. Интересно их исследовать)
Forwarded from Graph Machine Learning
Attending To Graph Transformers
by Luis Müller, Michael Galkin, Christopher Morris, and Ladislav Rampasek
arxiv
Our new survey on Graph Transformers (GTs) adjoined by some “mythbusting”.
We come up with categorization of GTs according to 4 main views:
🗺️ used Encodings,
🌐 expected Input Features (geometric or non-geometric),
✨ Tokenization (nodes, nodes+edges, subgraphs), and
🧮 Propagation (fully-connected, sparse, hybrid).
We investigate 4 common expectations and claims about GTs. Although conclusions are more nuanced (see the paper), we label them with pretentious badges ✅ Confirmed / ❌ Busted / 🤔 Plausible
1️⃣ Are GTs theoretically more expressive than GNNs?
❌ Busted. There is no inherent property of GTs that makes them more expressive. Instead, their expressivity stems from their positional/structural encodings. (And making those maximally expressive is as hard as solving the graph isomorphism problem.)
2️⃣ Can graph structure be effectively incorporated into GTs?
✅ Confirmed. GTs can identify graph edges (easy task), count triangles (medium), and distinguish regular graphs (hard task). But there is still room for improvement.
3️⃣ Does global attention reduce over-smoothing?
🤔 Plausible. In heterophilic graphs, GTs clearly outperform vanilla GNNs but still lag behind specialized SOTA models. Maybe we need a different structural bias?
4️⃣ Do GTs alleviate over-squashing better than GNN models?
🤔 Plausible. The Transformer perfectly solves NeighborsMatch where GNNs struggle. However, this is a synthetic “retrieval” task that doesn’t test (sub)graph representation.
🎁 Bonus: Attention matrices contain meaningful patterns and explain GT performance.
❌ Busted. We couldn’t find any strong interpretability of attention scores for downstream tasks. We suggest following Bertology in NLP that moved from dissecting attention to designing benchmarks.
by Luis Müller, Michael Galkin, Christopher Morris, and Ladislav Rampasek
arxiv
Our new survey on Graph Transformers (GTs) adjoined by some “mythbusting”.
We come up with categorization of GTs according to 4 main views:
🗺️ used Encodings,
🌐 expected Input Features (geometric or non-geometric),
✨ Tokenization (nodes, nodes+edges, subgraphs), and
🧮 Propagation (fully-connected, sparse, hybrid).
We investigate 4 common expectations and claims about GTs. Although conclusions are more nuanced (see the paper), we label them with pretentious badges ✅ Confirmed / ❌ Busted / 🤔 Plausible
1️⃣ Are GTs theoretically more expressive than GNNs?
❌ Busted. There is no inherent property of GTs that makes them more expressive. Instead, their expressivity stems from their positional/structural encodings. (And making those maximally expressive is as hard as solving the graph isomorphism problem.)
2️⃣ Can graph structure be effectively incorporated into GTs?
✅ Confirmed. GTs can identify graph edges (easy task), count triangles (medium), and distinguish regular graphs (hard task). But there is still room for improvement.
3️⃣ Does global attention reduce over-smoothing?
🤔 Plausible. In heterophilic graphs, GTs clearly outperform vanilla GNNs but still lag behind specialized SOTA models. Maybe we need a different structural bias?
4️⃣ Do GTs alleviate over-squashing better than GNN models?
🤔 Plausible. The Transformer perfectly solves NeighborsMatch where GNNs struggle. However, this is a synthetic “retrieval” task that doesn’t test (sub)graph representation.
🎁 Bonus: Attention matrices contain meaningful patterns and explain GT performance.
❌ Busted. We couldn’t find any strong interpretability of attention scores for downstream tasks. We suggest following Bertology in NLP that moved from dissecting attention to designing benchmarks.
Forwarded from Это разве аналитика?
Подборка материалов по ускорению работы таблиц на кликхаусе
Паттерны работы с кликом
Интересный паттерн клика - не надо бояться больших таблиц. Действительно больших) и здесь на первое место по оптимизации выходят такая штука как кодеки сжатия столбцов.
Видео про оптимизацию больших таблиц
Хорошая статья altinity про кодеки и lowcardinality
Методика тестирования различных кодеков
Паттерны работы с кликом
Интересный паттерн клика - не надо бояться больших таблиц. Действительно больших) и здесь на первое место по оптимизации выходят такая штука как кодеки сжатия столбцов.
Видео про оптимизацию больших таблиц
Хорошая статья altinity про кодеки и lowcardinality
Методика тестирования различных кодеков
Хабр
Эффективное использование ClickHouse. Алексей Миловидов (Яндекс)
Так как ClickHouse является специализированной системой, при его использовании важно учитывать особенности его архитектуры. В этом докладе Алексей расскажет о примерах типичных ошибок при...
Forwarded from тревожный эйчар
Как сблизиться с командой? Памятка для руководителей и эйчаров
Когда сотрудники молчат о своих переживаниях, руководители и эйчары не получают честной обратной связи. Проблемы не проговариваются и компания медленно деградирует. Как разбить стену отчуждения, восстановить доверие и замотивировать людей?
1️⃣ Интересуйтесь состоянием сотрудников. Оторвитесь от работы и спросите у коллеги, как дела. Сделайте это, даже если вам неловко, — в этом и заключается лидерство. Только не стоит навязывать разговор, если человек не хочет. Главное, чтобы каждый мог свободно рассказывать о наболевшем при необходимости.
2️⃣ Начните делиться эмоциями. Если для вас это комфортно, открыто расскажите сотрудникам о своих чувствах или личной проблеме. Когда вы не скрываете свою уязвимость, остальным становится безопаснее в вашем присутствии. В перспективе людям будет проще и приятнее работать вместе с вами и выкладываться на полную.
3️⃣ Поощряйте сотрудников отдыхать. Больше четверти людей не уходят в отпуск больше чем на четыре дня, а абсолютное большинство по итогам года не отгуливает отпуск целиком. Проблема в том, что отпусками и отгулами пренебрегают сами руководители. В компаниях, где руководители спокойно отрываются от работы, чтобы восстановить силы, сотрудники следуют их примеру.
4️⃣ Постарайтесь увидеть человека в каждом сотруднике. Многие компании декларируют подобные ценности на бумаге, но на практике руководители и эйчары часто фокусируются на совсем других вещах. Хотя практика показывает, что люди со здоровой психикой активнее вовлекаются в работу и в конечном итоге приносят больше пользы бизнесу.
🔗 Как обстановка на работе отражается на психическом здоровье — смотрите по ссылке
тревожный эйчар | психологическая поддержка команд
Когда сотрудники молчат о своих переживаниях, руководители и эйчары не получают честной обратной связи. Проблемы не проговариваются и компания медленно деградирует. Как разбить стену отчуждения, восстановить доверие и замотивировать людей?
1️⃣ Интересуйтесь состоянием сотрудников. Оторвитесь от работы и спросите у коллеги, как дела. Сделайте это, даже если вам неловко, — в этом и заключается лидерство. Только не стоит навязывать разговор, если человек не хочет. Главное, чтобы каждый мог свободно рассказывать о наболевшем при необходимости.
2️⃣ Начните делиться эмоциями. Если для вас это комфортно, открыто расскажите сотрудникам о своих чувствах или личной проблеме. Когда вы не скрываете свою уязвимость, остальным становится безопаснее в вашем присутствии. В перспективе людям будет проще и приятнее работать вместе с вами и выкладываться на полную.
3️⃣ Поощряйте сотрудников отдыхать. Больше четверти людей не уходят в отпуск больше чем на четыре дня, а абсолютное большинство по итогам года не отгуливает отпуск целиком. Проблема в том, что отпусками и отгулами пренебрегают сами руководители. В компаниях, где руководители спокойно отрываются от работы, чтобы восстановить силы, сотрудники следуют их примеру.
4️⃣ Постарайтесь увидеть человека в каждом сотруднике. Многие компании декларируют подобные ценности на бумаге, но на практике руководители и эйчары часто фокусируются на совсем других вещах. Хотя практика показывает, что люди со здоровой психикой активнее вовлекаются в работу и в конечном итоге приносят больше пользы бизнесу.
🔗 Как обстановка на работе отражается на психическом здоровье — смотрите по ссылке
тревожный эйчар | психологическая поддержка команд
Forwarded from Варим МЛ
Популярный вопрос - что нужно знать, чтобы продуктивно у нас работать? Попробовал на него ответить в очередном лонг-риде.
#Жека #machinelearning
#Жека #machinelearning
Telegraph
Что надо знать сотруднику Цельса?
Недавно в комментариях к одному из постов меня спросили, какие навыки и знания нужны, чтобы у нас работать. Вопрос на самом деле очень важный - без правильного ответа невозможно нормально выстроить процессы найма и развития сотрудников. Можно быстро набросать…
Forwarded from New Yorko Times (Yury Kashnitsky)
О проекте, который надо было убить
#ml #career #fail #coolstorybob
Если меня на собесе просят “рассказать про какой-нибудь проект” (в такой формулировке – плохой вопрос) или “описать случай, когда я принял непопулярное решение” (куда лучше), то я теперь эту историю рассказываю – как пришел в компанию и с порога прибил проект.
Немного предыстории для контекста. Пришёл я в текущую компанию в апреле 2020, как раз как лохдаун обьявили, а дочке исполнилось 4 месяца. Работа с дивана, порой дитё подсовывают, когда дебажишь, поначалу по 5 звонков в день, чтоб во все вникнуть, доступов еще нет, мак не привезли из-за бешеного спроса во время ковида – в-общем, было весело. Пришел синьором, а подопечных всего трое, причем неформально, и двух из них я скоро потерял. Девушка-миддл, которая меня вводила в курс дела, почти сразу ушла недели на 3 в бёрнаут, еще полгода мучалась и в итоге уволилась (у нее ADHD, а ковидное одиночество привело к бессоннице и куче проблем со здоровьем) - планировала изучать мозг, чтоб лучше понимать, что у нее самой в мозгу происходит. А толкового пацана-джуна продолбали сами, ему два раза продлевали временный контракт, и по закону Нидерландов с 3-го раза обязаны были дать постоянный, а одобренного бюджета на это не было. И так я остался на время с одной индусской, которая топ, но все же.
Один из проектов, который я перенял – LaQua, language quality assessment, эдакий PoC (proof of concept), затянувшийся на полтора года. Примерно в 10% случаев ревьюеры отшивают статьи из-за низкого качества языка, и хочется автоматически находить совсем уж дико написанные статьи. К тому же, одна из схем монетизации – можно подсветить плохо написанные абзацы и посоветовать обратиться к сервису proof-reading. На момент моего прихода бизнес-ожидания были колоссальные, хотели что-то типа научной версии Grammarly, был, конечно, и mismanagement, т.к. сильно доверились синьору, который был до меня и неплохо так наломал дров (чувак – с синдромом Ph.D.-гая, даже по оставшимся от него тикетам было видно, что он только и делал что архив читал, а про прод и Валуе (аминь!) не особо думал).
Еще проверка гипотезы затянулась, т.к. уж больно хорош, как кажется, датасет – сотни тысяч статей, прошедших через сервис по пруф-ридингу, т.е у нас было много пар вида “оригинальное предложение; его поправленная версия”. Пришел, чекнул, что есть, как seq2seq задача совсем не заводилась, ладно, пытаемся зафайнтюнить SciBERT на бинарную классификацию "хорошее vs. плохое предложение”. И тут я понимаю, что все что чуваки делали работает примерно на уровне шума. За месяц проверил сам пару гипотез (хотелось как регрессию решить, предсказывать левенштейна, т.е. как сильно надо поправить оригинальный параграф), и устроил внутри команды своего рода Толоку из Экселя, палок и изоленты – быстро чекнули гипотезу, что мы сами вообще можем отличить хорошие параграфы от плохих. На выходе - 60% точности (если подсвечиваем параграф текста как плохой, это только на 60% верно), да еще и black box.
Идей, конечно, много было, там и Grammarly опубликовали свой алгоритм, да и просто крутая тема (у Grammarly, говорят, в проде не нейронки, но тссс….). Но все же если фэйлить, то надо быстро. Вот я и собрал всех оунеров, менеджеров, представился, и донес до них, что наши попытки пора прикрыть и лучше переключиться на оценку сторонних решений типа Grammarly. То есть я рекомендовал не полностью прибить проект, а просто купить продукт, вместо того, чтоб парой джунов и одним синьором сделать его с нуля. Зашло неплохо, удивился, как адекватно это воспринял и мой менеджер, и прочие. Такой вот конструктивно-негативный опыт, вроде и фэйл, но вроде и нет. Вывод: всегда надо держать в уме вариант, что проект, который ты сейчас тащишь, воообще-то может быть выгодно прибить. И хорошо бы иметь весомые аргументы, чтоб (самому себе) объяснить, почему проект должен существовать. Конечно, когда дают свободу делать PoC, все не так жестко, но тем не менее, надо понимать, что вместо текущего исследовательского проектика ты вообще-то можешь делать другой, потенциально очень прибыльный.
#ml #career #fail #coolstorybob
Если меня на собесе просят “рассказать про какой-нибудь проект” (в такой формулировке – плохой вопрос) или “описать случай, когда я принял непопулярное решение” (куда лучше), то я теперь эту историю рассказываю – как пришел в компанию и с порога прибил проект.
Немного предыстории для контекста. Пришёл я в текущую компанию в апреле 2020, как раз как лохдаун обьявили, а дочке исполнилось 4 месяца. Работа с дивана, порой дитё подсовывают, когда дебажишь, поначалу по 5 звонков в день, чтоб во все вникнуть, доступов еще нет, мак не привезли из-за бешеного спроса во время ковида – в-общем, было весело. Пришел синьором, а подопечных всего трое, причем неформально, и двух из них я скоро потерял. Девушка-миддл, которая меня вводила в курс дела, почти сразу ушла недели на 3 в бёрнаут, еще полгода мучалась и в итоге уволилась (у нее ADHD, а ковидное одиночество привело к бессоннице и куче проблем со здоровьем) - планировала изучать мозг, чтоб лучше понимать, что у нее самой в мозгу происходит. А толкового пацана-джуна продолбали сами, ему два раза продлевали временный контракт, и по закону Нидерландов с 3-го раза обязаны были дать постоянный, а одобренного бюджета на это не было. И так я остался на время с одной индусской, которая топ, но все же.
Один из проектов, который я перенял – LaQua, language quality assessment, эдакий PoC (proof of concept), затянувшийся на полтора года. Примерно в 10% случаев ревьюеры отшивают статьи из-за низкого качества языка, и хочется автоматически находить совсем уж дико написанные статьи. К тому же, одна из схем монетизации – можно подсветить плохо написанные абзацы и посоветовать обратиться к сервису proof-reading. На момент моего прихода бизнес-ожидания были колоссальные, хотели что-то типа научной версии Grammarly, был, конечно, и mismanagement, т.к. сильно доверились синьору, который был до меня и неплохо так наломал дров (чувак – с синдромом Ph.D.-гая, даже по оставшимся от него тикетам было видно, что он только и делал что архив читал, а про прод и Валуе (аминь!) не особо думал).
Еще проверка гипотезы затянулась, т.к. уж больно хорош, как кажется, датасет – сотни тысяч статей, прошедших через сервис по пруф-ридингу, т.е у нас было много пар вида “оригинальное предложение; его поправленная версия”. Пришел, чекнул, что есть, как seq2seq задача совсем не заводилась, ладно, пытаемся зафайнтюнить SciBERT на бинарную классификацию "хорошее vs. плохое предложение”. И тут я понимаю, что все что чуваки делали работает примерно на уровне шума. За месяц проверил сам пару гипотез (хотелось как регрессию решить, предсказывать левенштейна, т.е. как сильно надо поправить оригинальный параграф), и устроил внутри команды своего рода Толоку из Экселя, палок и изоленты – быстро чекнули гипотезу, что мы сами вообще можем отличить хорошие параграфы от плохих. На выходе - 60% точности (если подсвечиваем параграф текста как плохой, это только на 60% верно), да еще и black box.
Идей, конечно, много было, там и Grammarly опубликовали свой алгоритм, да и просто крутая тема (у Grammarly, говорят, в проде не нейронки, но тссс….). Но все же если фэйлить, то надо быстро. Вот я и собрал всех оунеров, менеджеров, представился, и донес до них, что наши попытки пора прикрыть и лучше переключиться на оценку сторонних решений типа Grammarly. То есть я рекомендовал не полностью прибить проект, а просто купить продукт, вместо того, чтоб парой джунов и одним синьором сделать его с нуля. Зашло неплохо, удивился, как адекватно это воспринял и мой менеджер, и прочие. Такой вот конструктивно-негативный опыт, вроде и фэйл, но вроде и нет. Вывод: всегда надо держать в уме вариант, что проект, который ты сейчас тащишь, воообще-то может быть выгодно прибить. И хорошо бы иметь весомые аргументы, чтоб (самому себе) объяснить, почему проект должен существовать. Конечно, когда дают свободу делать PoC, все не так жестко, но тем не менее, надо понимать, что вместо текущего исследовательского проектика ты вообще-то можешь делать другой, потенциально очень прибыльный.
Forwarded from Кодим на Коленке | Уроки по программированию
Курс по базам данных для начинающих
Серия уроков по серверам баз данных. Как установить базу данных, как настроить доступ, как сделать бэкап, как создать кластер базы данных, как настроить репликацию таблиц, базы данных. Ответы на эти вопросы вы получите в данном видеокурсе.
Подробнее: 👉 тут
#видео #бд
Серия уроков по серверам баз данных. Как установить базу данных, как настроить доступ, как сделать бэкап, как создать кластер базы данных, как настроить репликацию таблиц, базы данных. Ответы на эти вопросы вы получите в данном видеокурсе.
Подробнее: 👉 тут
#видео #бд
Forwarded from DevFM
Буфферный кеш в PostgreSQL
Очередная серия статей от ребят из postgres. На этот раз о механизме журналирования, он же write-ahead log, он же WAL. Статьи не из лёгких и требуют серьезного погружения.
В первой статье автор рассказывает о такой важной штуке, как буферный кеш. Буферный кеш представляет собой массив буферов, каждый буфер – это место под одну страницу данных. Чтобы работать с данными, процессы читают страницы в кеш, тем самым далее экономя на обращениях к диску. Для поиска страниц в кеше используются хеш-таблицы, но, конечно, со своими нюансиками.
Когда кеш переполняется, что-то нужно вытеснить. Для этого используется алгоритм clock-sweep, который по кругу перебирает все буферы, уменьшает счётчики обращений, учитывает ещё разную хитрую магию и решает кого бы вытеснить.
Чтобы потрогать кеш руками, есть расширение pg_buffercache. С помощью специального запроса можно посмотреть количество страниц, счётчик обращений ним, привязку к процессу. Также можно узнать, какая часть каких таблиц закеширована и насколько активно используются эти данные.
Размер кеша – это, что рекомендуют менять сразу после развёртывания базы. По умолчанию он равен 128 Мб. Нет конкретного значения, которое стоит выбрать для кеша, всё зависит от задачи и лучше выяснять на практике. Автор рекомендует взять для начала 1/4 оперативной памяти. Также стоит учитывать, что postgres использует обычные вызовы операционной системы, поэтому происходит двойное кеширование – кеш СУБД и кеш ОС.
Горячий вопрос: прогрев кеша. В postgres для этого есть расширение pg_prewarm. С помощью него можно сразу прочитать в кеш данные определённых таблиц. Также можно сохранять состояние кеша и восстанавливать после перезагрузки сервера.
Далее в серии: статья о том как устроен журнал предзаписи и как используется для восстановления после сбоев, зачем нужны и как настраиваются контрольные точки, уровни журнала и их назначение, а также о производительности журналирования.
#skills #database
Очередная серия статей от ребят из postgres. На этот раз о механизме журналирования, он же write-ahead log, он же WAL. Статьи не из лёгких и требуют серьезного погружения.
В первой статье автор рассказывает о такой важной штуке, как буферный кеш. Буферный кеш представляет собой массив буферов, каждый буфер – это место под одну страницу данных. Чтобы работать с данными, процессы читают страницы в кеш, тем самым далее экономя на обращениях к диску. Для поиска страниц в кеше используются хеш-таблицы, но, конечно, со своими нюансиками.
Когда кеш переполняется, что-то нужно вытеснить. Для этого используется алгоритм clock-sweep, который по кругу перебирает все буферы, уменьшает счётчики обращений, учитывает ещё разную хитрую магию и решает кого бы вытеснить.
Чтобы потрогать кеш руками, есть расширение pg_buffercache. С помощью специального запроса можно посмотреть количество страниц, счётчик обращений ним, привязку к процессу. Также можно узнать, какая часть каких таблиц закеширована и насколько активно используются эти данные.
Размер кеша – это, что рекомендуют менять сразу после развёртывания базы. По умолчанию он равен 128 Мб. Нет конкретного значения, которое стоит выбрать для кеша, всё зависит от задачи и лучше выяснять на практике. Автор рекомендует взять для начала 1/4 оперативной памяти. Также стоит учитывать, что postgres использует обычные вызовы операционной системы, поэтому происходит двойное кеширование – кеш СУБД и кеш ОС.
Горячий вопрос: прогрев кеша. В postgres для этого есть расширение pg_prewarm. С помощью него можно сразу прочитать в кеш данные определённых таблиц. Также можно сохранять состояние кеша и восстанавливать после перезагрузки сервера.
Далее в серии: статья о том как устроен журнал предзаписи и как используется для восстановления после сбоев, зачем нужны и как настраиваются контрольные точки, уровни журнала и их назначение, а также о производительности журналирования.
#skills #database
Хабр
WAL в PostgreSQL: 1. Буферный кеш
Предыдущий цикл был посвящен изоляции и многоверсионности PostgreSQL, а сегодня мы начинаем новый — о механизме журналирования (write-ahead logging). Напомню, что материал основан на учебных курсах по...
Forwarded from Alexandra
Всегда пользовалась этими двумя таблицами в таких вопросах