Это был обычный понедельник. Я пил кофе, проверял почту, и вдруг — волна уведомлений в Slack. «Сайт не грузится!», «Отчеты зависли!», «Что происходит?».
Привет!
Недавно в рамках одного из проектов на стеке KMP, Ktor и Kotlin Serialization мы с командой решили провести эксперимент и определить возможность и целесобразность минификации тел запросов / ответов на Json.
Да, мы знаем про GraphQL, Protobuf и др., но в нашем случае имел место необузданный интерес наколхозить такое решение. И при всей его наивности удалось сократить средний размер итоговых джсонов (после всех внутренних оптимизаций) на 15–20%.
Вводные данные:
Большое приложение на KMP с таргетами iOS, Android, Web и Desktop;
Фронтенд и бэкенд написаны на Ktor и швыряются Json'ами по HTTP;
Если задать вопрос искусственному интеллекту “зачем нужна ERP-система” мы получим следующий ответ:
«ERP‑система нужна для упрощения, автоматизации и эффективного управления бизнес‑процессами в организации. Она собирает важные данные в одном месте, чтобы их анализировать и решать задачи бизнеса.»
Добрый день!
Предлагаю рассмотреть план выполнения следующего простого запроса:
select
code,
model,
avg(price) over (partition by model) avgp
from
pc
(В данной статье используется таблица из базы данных «Компьютеры» обучающего ресурса sql-ex.ru, ссылка на скрипт)
Запрос выводит все строки из таблицы PC (поля code и model) с расчетом средней стоимости по модели:
Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?
В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.
Частный случай повышения производительности работы модуля Диадок на конфигурации УТ 10.3. Испробованы способы типовой оптимизации от 1С путем добавления ресурса в индексированные поля. Но результат дал только способ с нарушением рекомендаций 1С.
Добрый день коллеги.
Обычно я не пишу статей, но решился на этот опус из соображений массовости использования решения Контура модуль Диадок для 1С. Также понимаю, что многие еще используют УТ 10.3 или УПП и могут сталкиваться с похожей деградацией.
Индексы — важнейший инструмент оптимизации запросов в базах данных. В PostgreSQL одним из вариантов является хеш-индекс. В отличие от B-tree, он работает исключительно с операциями равенства (=) и использует бакеты для хранения ссылок на строки таблицы. Давайте разберёмся, как PostgreSQL управляет этими бакетами, какие особенности у хеш-индекса и в каких случаях его применение оправдано.
При создании хеш-индекса PostgreSQL применяет хеш-функцию к каждому значению индексируемого столбца. Результат хеширования определяет, в какой бакет (bucket) попадёт запись.
Статей о GPT написано уже немало, и многие знакомые мне аналитики заявляют, что ни разу не использовали его возможности. Ввиду этого, я хочу подробно раскрыть эту тему, предоставив практические примеры и доказательства эффективности.
Пользователи PostgreSQL нередко оперируют аналитическими запросамиЧитать полностью »
