Недавно я протестировал мобильную версию Where Winds Meet — эпической RPG в жанре Wuxia, действие которой разворачивается в Китае X века. Игра уже доступна в режиме предварительной загрузки, и я прошёл путь от установки до оценки функционала, включая работу сервиса LagoFast для перевода интерфейса. Делюсь объективным отчётом о своих впечатлениях.

Этап 1. Предварительная загрузка и установка

Перед официальным стартом бета-версии (запланирован на 12 декабря 2025 года, 8:00 AM UTC+8) игра находится в режиме Pre-download mode. На экране отображается сообщение:

«Pre-download mode active. Please wait for the mobile open beta starting on December 12, 2025 at 8:00 AM (UTC+8)».

Что происходит в этом режиме:

• автоматически скачиваются ключевые ресурсы игры;

• сохраняется прогресс загрузки — не нужно начинать с нуля после перезапуска;

• функционал ограничен до официального релиза.

Требования к устройству:

• Android 7.1+ с 8 ГБ ОЗУ или iOS 15 и выше;

• стабильное интернет-соединение;

• достаточное свободное место на устройстве (объём загружаемых данных — несколько ГБ).

Установка прошла стандартно:

1. Скачал игру из Google Play (Android) .

2. После установки и авторизации пользователя система автоматически запустила загрузку библиотек и файлов.

Этап 2. Загрузка ресурсов: что нужно знать

После запуска началась последовательная загрузка компонентов:

• Core Resources — базовые файлы для работы локаций и механик (критичны для запуска);

• Expanded Resources — дополнительные декоративные элементы;

• Appearance — ресурсы для внешности персонажей (например, Appearance 0M/2.0G).

Особенности:

• порядок загрузки фиксирован — нельзя пропустить этап;

• время скачивания зависит от скорости интернета;

• при паузе доступна кнопка «Resume» для продолжения;

• опция «Allow download on cellular data» позволяет использовать мобильный интернет (рекомендуется Wi-Fi).

Этап 3. Авторизация: варианты входа

После загрузки ресурсов появилось меню «Switch Account» с вариантами входа:

• NetEase Games — основной аккаунт (оптимален для кросс-платформенной игры);

• Google, Guest, Sign in with Apple — быстрые способы входа;

• Facebook, Steam, Epic Games, X, PSN — для синхронизации с другими платформами.

Вывод: система авторизации гибкая, поддерживает множество платформ. Для сохранения прогресса лучше использовать NetEase Games.

Этап  4. Первые впечатления от интерфейса и предварительной загрузки (накануне официального запуска)

Сегодня, 11 декабря 2025 года, за сутки до официального старта мобильной открытой беты (12 декабря 2025 года, 8:00 AM UTC+8), я протестировал текущее состояние мобильной версии Where Winds Meet — вплоть до загрузочного экрана и настройки вспомогательных сервисов.

Важно подчеркнуть: на данный момент полноценный геймплей ещё недоступен — игра находится в режиме предварительной загрузки. Поэтому оценка касается:

• процесса установки и инициализации;

• интерфейса авторизации;

• работы сервиса перевода (на уровне меню и загрузочных экранов).

Что удалось проверить

1. Процесс загрузки ресурсов

   • Система корректно скачивает Core Resources, Expanded Resources и Appearance (например, блок Appearance 0M/2.0G).

   • Статус «Waiting for prior resource download» отображается адекватно, указывая на последовательную загрузку компонентов.

   • Кнопка «Resume» работает: позволяет возобновить процесс после паузы.

   • Опция «Allow download on cellular data» функционирует, но для больших объёмов данных (2 ГБ+) рекомендуется Wi‑Fi.

2. Система авторизации

   • Меню «Switch Account» предлагает все заявленные способы входа (NetEase Games, Google, Apple, Steam и др.).

   • Синхронизация с учётной записью NetEase Games прошла без ошибок — прогресс с ПК‑версии отображается в интерфейсе.

   • Режим Guest доступен, но предупреждает о невозможности сохранения прогресса.

3. Работа LagoFast (перевод интерфейса)

   • После предоставления разрешений (всплывающие окна и запись видео) сервис активируется.

   • Замечена небольшая задержка (~2–3,5 секунды("+"-")) при обновлении переведённого текста.

   • Смещение шрифтов при экранном переводе(местами).

Что пока недоступно для тестирования

• Управление в бою и паркур — механика сенсорного управления не проверялась, так как игра не запущена.

• Диалоги NPC — тестирование перевода диалогов невозможно до входа в игровые локации.

• Загрузка локаций — оценить скорость перехода между зонами или FPS в реальном геймплее пока нельзя.

• Интерфейс инвентаря и карты — элементы UI в процессе исследования мира не тестировались.

Выводы на текущий момент

На этапе предварительной загрузки мобильная версия Where Winds Meet демонстрирует:

• Стабильность базовых процессов (установка, авторизация, загрузка ресурсов).

• Работоспособность кросс‑платформенного прогресса — синхронизация с ПК‑версией работает.

• Потенциал LagoFast как инструмента для локализации, хотя с оговорками (задержки, неполный охват терминов, смещение шрифтов при экранном переводе(местами).

Рекомендации перед запуском 12 декабря:

1. Убедитесь, что загрузка ресурсов завершена.

2. Проверьте разрешения для LagoFast (если используете перевод).

3. Подключите устройство к Wi‑Fi для минимизации задержек.

4. Сохраните резервную копию учётной записи (особенно если играете через Guest).

Официальное открытие игры завтра даст возможность оценить геймплей в полном объёме. Пока же можно констатировать: подготовительные этапы реализованы корректно, а сервис перевода уже сейчас облегчает взаимодействие с интерфейсом.

P.S. В сообществах игроков встречаются упоминания о сложностях при установке мобильной версии Where Winds Meet. На моём устройстве процесс загрузки из официального магазина приложений (Google Play/App Store) прошёл без нареканий — всё установилось корректно, начата предварительная загрузка ресурсов.

В целях всесторонней проверки планирую дополнительно протестировать установку через APK‑файл (из одного из доступных интернет‑источников). Это позволит:

• оценить различия между официальным и альтернативным способами установки;

• выявить возможные нюансы совместимости или предупреждения системы безопасности;

• сравнить скорость загрузки и целостность файлов.

Результаты тестирования (включая возможные ошибки, время установки и особенности работы игры после неё) будут подробно описаны в следующей статье. Цель — предоставить объективную информацию, которая поможет другим игрокам при выборе способа установки.

Предисловие

В мире высоконагруженных баз данных выбор метода пагинации может стать решающим фактором для производительности системы. Эксперимент, проведённый с двумя подходами — классическим ROW_NUMBER и отложенным соединением (Deferred Join) — показал, что даже архитектурно более совершенный метод не гарантирует победы без тонкой настройки СУБД. Исследование раскрывает, как правильная конфигурация памяти PostgreSQL перевесила преимущества Deferred Join и позволила ROW_NUMBER добиться превосходства на параллельной нагрузке до 22 сессий.

Начало экспериментов с методом пагинации ROW_NUMBER

Прогноз нейросети

Вопрос

Используя информацию о размерах таблиц, схеме баз данных и тестовых запросах, дай прогноз и обоснование - какой тестовый запрос покажет большую производительность для нагрузочного тестирования с параллельной нагрузкой от 5 до 22 сессий для СУБД PostgreSQL 17 c ресурсами CPU=8 RAM=8GB

Прогноз:
Наибольшую производительность при параллельной нагрузке (5–22 сессии) покажет запрос plan-1 (ROW_NUMBER()) после оптимизации индексами.

Экспериментальная проверка

Анализ ситуации нейросетью

Почему не оправдался прогноз нейросети о большей эффективности метода ROW_NUMBER для заданных условий ?

5. Условия, при которых ROW_NUMBER() действительно был бы эффективнее:

Сценарий 2: Адекватный размер work_mem

Если бы work_mem был ≥ 256MB для сортировки в памяти

какие значение work_mem необходимо установить для получения преимущества метода row_number при максимальной нагрузке 22 параллельные сессии при общем размере RAM=8GB ?

-- Для получения преимущества ROW_NUMBER():
SET work_mem = '180MB';
SET max_parallel_workers_per_gather = 1;
SET max_parallel_workers = 16;

-- В postgresql.conf:
work_mem = 180MB
max_parallel_workers_per_gather = 1
max_parallel_workers = 16
max_worker_processes = 16
shared_buffers = 2GB
effective_cache_size = 6GB

Задача

Экспериментальная проверка рекомендации нейросети по оптимизации метода пагинации ROW_NUMBER

Изменение конфигурационных параметров СУБД

ALTER SYSTEM SET work_mem = '180MB';

ALTER SYSTEM SET max_parallel_workers_per_gather = 1;

ALTER SYSTEM SET max_parallel_workers = 16;

ALTER SYSTEM SET max_worker_processes = 16 ;

ALTER SYSTEM SET shared_buffers = '2GB';

ALTER SYSTEM effective_cache_size = '6GB';

Производительность и ожидания СУБД в ходе нагрузочного тестирования

Операционная скорость

Результат

Среднее превышение операционной скорости , при использовании метода ROW_NUMBER составило 12.59%

Ожидания СУБД

Результат

Среднее снижение ожиданий СУБД, при использовании метода ROW_NUMBER составило 18.06%

Характерные особенности тестовых запросов и планов выполнения

1. Общая цель запросов

Оба запроса решают задачу случайной пагинации (выбор случайной "страницы" из 100 строк) для отфильтрованных данных (билеты с бизнес-классом).

2. Основные различия в подходах

Первый запрос (ROW_NUMBER()):

• Использует оконную функцию ROW_NUMBER() для нумерации всех строк

• Фильтрует по диапазону номеров строк после нумерации

• Ключевая проблема: Выполняет полную сортировку и нумерацию всех 2.15 млн строк

Второй запрос (Deferred Join):

• Использует отложенное соединение (deferred join)

• Сначала выбирает только ticket_no с помощью OFFSET/LIMIT

• Затем соединяет остальные данные по отобранным ключам

• Преимущество: Сортирует только ключи, а не все данные

3. Производительность

Первый запрос:

• Время выполнения: 12.65 секунд

• Основные затраты:
  Merge Semi Join: 9.3 секунды
  Сортировка 2.15 млн строк: 850-1000 мс (quicksort, 170 МБ памяти)
  WindowAgg (оконная функция): 1723 мс

Второй запрос:

• Время выполнения: ~16.1 секунды (неполные данные в выводе)

• Основные затраты:
  Merge Semi Join: 8.75 секунды
  Сортировка для OFFSET: 5.5 секунды (top-N heapsort, 15 МБ памяти)
  Hash Join: 5575 мс

4. Критические различия в планах

Сортировка:

1. Первый запрос: Сортирует все столбцы (ticket_no, book_ref, passenger_name) - 92 байта на строку

2. Второй запрос: Сортирует только ticket_no - 32 байта на строку

Использование памяти:

1. Первый: 170 МБ для сортировки всех данных

2. Второй: 15 МБ для сортировки только ключей

Фильтрация:

1. Первый: Сначала нумерует все строки, затем фильтрует 100

2. Второй: Сначала выбирает 100 ключей, затем соединяет данные

5. Проблемы обоих подходов

1. Общая проблема: floor(random() * COUNT(*)/100) требует полного сканирования для подсчета строк

2. Производительность OFFSET: Во втором запросе OFFSET должен "пропустить" много строк (случайная страница * 100)

6. Рекомендации

Для оптимизации:

1. Второй подход лучше архитектурно (deferred join), но в данном случае медленнее из-за:
   Необходимости вычислять OFFSET
   Hash Join вместо более эффективного соединения

2. Потенциальные улучшения:
   Использовать keyset pagination вместо OFFSET
   Кэшировать общее количество строк
   Рассмотреть материализованные представления для filtered_tickets

В текущей реализации:

• Первый запрос быстрее (12.65с vs ~16.1с), но использует больше памяти

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

7. Вывод

Оба запроса имеют проблемы с производительностью из-за необходимости обработки всех 2.15 млн строк для случайной выборки. Deferred Join (второй подход) - более правильная архитектурная паттерн, но требует оптимизации OFFSET и соединения для повышения эффективности в данном конкретном случае.

Характерные особенности производительности СУБД

1. Производительность (SPEED)

ROW_NUMBER подход:

• Начальная производительность: 60

• Стабильная после 45 итерации: 96

• Максимум: 96 (после адаптации)

• Прирост: 60 → 96 (+60%)

Deferred Join подход:

• Начальная производительность: 52

• Стабильная после 55 итерации: 84

• Максимум: 84

• Прирост: 52 → 84 (+61.5%)

Вывод: ROW_NUMBER показывает на 14.3% выше абсолютную производительность (96 vs 84).

2. Динамика адаптации

ROW_NUMBER:

• Быстрый рост до 96 за 55 итераций

• Более резкие скачки производительности

• Ранняя стабилизация (с 55 итерации)

Deferred Join:

• Более плавный рост до 84

• Дольше адаптируется (до 55 итерации)

• Стабильнее на низких нагрузках

3. Ожидания и блокировки

ROW_NUMBER:

• TIMEOUT появляются с итерации 46 (при нагрузке 10 соединений)

• LWLOCK стабилизируются на уровне 3-6

• WAITINGS: 4-7

Deferred Join:

• IO ожидания появляются с итерации 73 (при нагрузке 15+ соединений)

• LWLOCK: 4-8 (выше, чем у ROW_NUMBER)

• WAITINGS: до 21 пикового значения

• Более выраженные скачки в ожиданиях (74 итерация: 21 ожидание)

4. Корреляция с нагрузкой

• Нагрузка растет от 5 до 22 соединений

• Критические точки:
  10 соединений (итерация 46): ROW_NUMBER начинает показывать TIMEOUT
  15 соединений (итерация 73): Deferred Join показывает IO ожидания
  18+ соединений: оба подхода стабилизируются на максимальных значениях ожиданий

5. Ключевые различия в поведении

ROW_NUMBER:

1. Выше пиковая производительность (96 vs 84)

2. Раннее появление TIMEOUT (с 10 соединений)

3. Меньше LWLOCK в среднем (3-6 vs 4-8)

4. Более предсказуемые паттерны ожиданий

Deferred Join:

1. Лучше масштабируется при низких нагрузках

2. Более стабильные WAITINGS (кроме пиков)

3. Появление IO ожиданий вместо TIMEOUT

4. Сильнее страдает от LWLOCK

6. Анализ проблемных точек

ROW_NUMBER:

• Проблема: TIMEOUT при 10+ соединениях

• Причина: WindowAgg + сортировка больших данных конкурируют за ресурсы

• Симптом: Конкуренция за CPU/память

Deferred Join:

• Проблема: IO ожидания при 15+ соединениях

• Причина: Hash Join + сортировка для OFFSET требуют disk I/O

• Симптом: Конкуренция за disk I/O и LWLOCK

7. Рекомендации по оптимизации

Для ROW_NUMBER:

1. Увеличить work_mem для уменьшения disk spills

2. Рассмотреть материализованные представления для filtered_tickets

3. Кэшировать COUNT(*) для random_page

Для Deferred Join:

1. Оптимизировать индексы для сортировки ticket_no

2. Увеличить shared_buffers для кэширования hash таблиц

3. Рассмотреть использование keyset pagination вместо OFFSET

8. Общий вывод

1. ROW_NUMBER лучше для:
   Максимальной производительности (14.3% выше)
   Систем с достаточными CPU/памятью
   Сценариев с <10 конкурентных соединений

2. Deferred Join лучше для:
   Систем с ограничениями по памяти
   Сценариев с предсказуемыми IO паттернами
   Приложений, чувствительных к TIMEOUT

3. Оба подхода требуют оптимизации при >10 конкурентных соединений

4. Критическая нагрузка: 10-15 соединений (точка деградации производительности)

Метрики производительности инфраструктуры

1. Использование CPU

ROW_NUMBER:

• Начало: 61% user, 3% system, 36% idle

• Критическая точка (итерация 50): резкий переход на 95-96% user, 4% system, 0% idle

• Стабильная нагрузка: 96% user, 4% system, 0% idle

• Вывод: Полная загрузка CPU с преобладанием пользовательского времени

Deferred Join:

• Начало: 61% user, 2% system, 36% idle

• Критическая точка (итерация 52): переход на 97% user, 3% system, 0% idle

• Стабильная нагрузка: 97% user, 3% system, 0% idle

• Вывод: Аналогичная полная загрузка, но меньше системного времени

Сравнение: Deferred Join показывает на 1% выше user CPU и на 1% ниже system CPU.

2. Использование памяти

ROW_NUMBER:

• Свободная память: 1791 → 2753 KB (+53% рост)

• Буферы: 47 → 6 KB (-87% снижение)

• Кэш: 4955 → 2751 KB (-44% снижение)

• Своп: 70 → 67 KB (минимальное изменение)

• Вывод: Активное использование кэша и буферов

Deferred Join:

• Свободная память: 4567 → 2207 KB (-51% снижение)

• Буферы: 18 → 6 KB (-67% снижение)

• Кэш: 2211 → 2728 KB (+23% рост)

• Своп: 69 → 73 KB (незначительный рост)

• Вывод: Увеличение использования кэша, снижение свободной памяти

Сравнение: ROW_NUMBER активнее использует кэш в начале, Deferred Join наращивает кэш в процессе.

3. Ввод-вывод (IO)

ROW_NUMBER:

• io_bo: 52 → 58 (+11.5% рост)

• Пиковые значения: до 59

• Вывод: Умеренный рост IO при увеличении нагрузки

Deferred Join:

• io_bo: 59 → 65 (+10% рост)

• Пиковые значения: до 68

• Вывод: Более высокий базовый уровень IO

Сравнение: Deferred Join имеет на 10-15% выше активность IO, что соответствует ожиданиям из предыдущего анализа (IO ожидания).

4. Системные метрики

ROW_NUMBER:

• Прерывания (system_in): 5687 → 8279 (+45% рост)

• Переключения контекста (system_cs): 657 → 1053 (+60% рост)

• Процессы в run queue (procs_r): 6 → 15 (+150% рост)

Deferred Join:

• Прерывания (system_in): 5652 → 8274 (+46% рост)

• Переключения контекста (system_cs): 652 → 1063 (+63% рост)

• Процессы в run queue (procs_r): 5 → 15 (+200% рост)

Сравнение: Оба подхода показывают схожий рост системных метрик, Deferred Join имеет немного больше переключений контекста.

5. Критические точки перехода

ROW_NUMBER:

• Итерация 50 (нагрузка 10): переход на 0% idle CPU

• Сопровождается: Ростом procs_r до 9

• Симптом: Резкое изменение паттерна использования памяти

Deferred Join:

• Итерация 52 (нагрузка 10): переход на 0% idle CPU

• Сопровождается: Ростом procs_r до 9

• Симптом: Снижение свободной памяти до 4000 KB

6. Корреляция с нагрузкой

• 5-8 соединений: Оба подхода работают с простоями CPU (36% idle)

• 10 соединений: Критическая точка (0% idle)

• 12-15 соединений: Стабилизация на максимальной нагрузке

• 18-22 соединений: Дальнейший рост системных метрик

7. Ключевые различия по метрикам

ROW_NUMBER преимущества:

1. Меньше IO операций (58 vs 68)

2. Лучшее использование памяти (растущая свободная память)

3. Более стабильный кэш (меньше колебаний)

Deferred Join преимущества:

1. Меньше системного времени CPU (3% vs 4%)

2. Более предсказуемое использование кэша (постепенный рост)

3. Меньше начальных буферов (более эффективное использование)

8. Проблемные паттерны

ROW_NUMBER:

• Проблема: Резкое падение кэша с 4955 до 2751

• Причина: Оконные функции требуют больших рабочих наборов

• Риск: Потенциальные page faults при недостатке памяти

Deferred Join:

• Проблема: Высокий базовый уровень IO (59 vs 52)

• Причина: Hash Join и сортировка для OFFSET

• Риск: Disk I/O bottlenecks при высокой нагрузке

9. Общие выводы по метрикам

1. Оба подхода CPU-bound: 0% idle при нагрузке ≥10 соединений

2. Deferred Join более IO-intensive: на 10-15% выше IO активность

3. ROW_NUMBER более memory-intensive: активнее использует кэш и буферы

4. Критическая нагрузка: 10 соединений для обоих подходов

5. Масштабирование: Deferred Join лучше сохраняет кэш, но требует больше IO

10. Рекомендации по оптимизации системы

Для ROW_NUMBER:

1. Увеличить work_mem для сортировки в памяти

2. Настроить shared_buffers для кэширования рабочих наборов

3. Мониторить page faults и swap активность

Для Deferred Join:

1. Оптимизировать индексы для уменьшения IO

2. Рассмотреть SSD для уменьшения latency IO операций

3. Настроить effective_io_concurrency для параллельного IO

Итог:

Выбор между подходами зависит от конфигурации системы -

• ROW_NUMBER для CPU-обеспеченных архитектур

• Deferred Join для систем с хорошим IO.

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

В этой статье показаны результаты нагрузочного тестирования PostgreSQL в условиях нагрузочного тестирования, которые привели к парадоксальному на первый взгляд выводу. Когда количество одновременных операций растет, а данные активно читаются, дорогостоящие индексы могут не справиться, превратившись из помощников во вредителей. И как оказалось, старый добрый Seq Scan — метод полного сканирования таблицы — неожиданно стал в итоге самым эффективным решением в этом сценарии.

Постановка экспериментов

Тестовая таблица

CREATE TABLE pgbench_test

(

aid integer PRIMARY KEY ,

bid integer,

abalance integer,

filler character(84)

);

ALTER TABLE pgbench_test ADD CONSTRAINT "pgbench_test_bid_fkey" FOREIGN KEY (bid) REFERENCES pgbench_branches(bid);

INSERT INTO pgbench_test ( aid , bid , abalance , filler )

SELECT

id ,

floor(random() * 685 ) + 1 ,

floor(random() * (68500000 - 1 + 1)) + 1 ,

md5(random()::text)

FROM generate_series(1,1000000) id;

Тестовый запрос

select test.abalance

from pgbench_accounts acc

join pgbench_test test on (test.bid = acc.bid )

where acc.aid = current_aid ;

Эксперимент-1 : Метод доступа Seq Scan

План выполнения тестового запроса

Стоимость плана = 21620.62

Gather (cost=1002.80..21620.62 rows=1460 width=4) (actual time=4.088..329.017 rows=1468 loops=1)

Workers Planned: 3

Workers Launched: 3

-> Hash Join (cost=2.80..20474.62 rows=471 width=4) (actual time=1.821..300.589 rows=367 loops=4)

Hash Cond: (test.bid = acc.bid)

-> Parallel Seq Scan on pgbench_test test (cost=0.00..19619.81 rows=322581 width=8) (actual time=0.692..263.390 rows=250000 loops=4)

-> Hash (cost=2.79..2.79 rows=1 width=4) (actual time=0.488..0.489 rows=1 loops=4)

Buckets: 1024 Batches: 1 Memory Usage: 9kB

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.472..0.474 rows=1 loops=4)

Index Cond: (aid = 51440641)

Planning Time: 1.977 ms

Execution Time: 329.301 ms

Эксперимент-2 : Метод доступа Bitmap Index Scan

CREATE INDEX pgbench_test_idx ON pgbench_test ( bid );

План выполнения тестового запроса

Стоимость плана = 1546.55

Nested Loop (cost=14.51..1546.55 rows=1460 width=4) (actual time=0.894..366.050 rows=1468 loops=1)

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.217..0.227 rows=1 loops=1)

Index Cond: (aid = 51440641)

-> Bitmap Heap Scan on pgbench_test test (cost=13.94..1529.17 rows=1460 width=8) (actual time=0.669..365.312 rows=1468 loops=1)

Recheck Cond: (bid = acc.bid)

Heap Blocks: exact=1407

-> Bitmap Index Scan on pgbench_test_idx (cost=0.00..13.57 rows=1460 width=0) (actual time=0.355..0.356 rows=1468 loops=1)

Index Cond: (bid = acc.bid)

Planning Time: 2.634 ms

Execution Time: 366.419 ms

Эксперимент-3 : Метод доступа Index Only Scan

CREATE INDEX idx_pgbench_test_bid_abalance ON pgbench_test(bid) INCLUDE (abalance);

План выполнения тестового запроса

Стоимость плана = 48.86

Nested Loop (cost=0.99..48.86 rows=1460 width=4) (actual time=0.771..1.186 rows=1432 loops=1)

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.736..0.737 rows=1 loops=1)

Index Cond: (aid = 51440641)

-> Index Only Scan using idx_pgbench_test_bid_abalance on pgbench_test test (cost=0.42..31.47 rows=1460 width=8) (actual time=0.029..0.289 rows=1432 loops=1)

Index Cond: (bid = acc.bid)

Heap Fetches: 0

Planning Time: 4.949 ms

Execution Time: 1.302 ms

Нагрузка на СУБД

Результаты экспериментов:

1. До 8-ми соединений - наибольшая производительность получена с использованием метода доступа Bitmap Index Scan.

2. После 8-ми соединений и до 22-х - наибольшая производительность получена с использованием метода доступа Seq Scan.

Причины эффективности Seq Scan при параллельной нагрузке

1. Увеличение нагрузки на подсистему ввода-вывода

• Без индекса: Sequential Scan читает данные большими последовательными блоками

• С индексом: Index Scans создают случайный доступ к диску

2. Конкуренция за буферный кэш

• Индекс занимает место в shared_buffers

• Вытесняет полезные данные из кэша

• Каждое соединение читает разные части индекса → больше промахов кэш

3. Блокировки в системных каталогах

• При использовании индекса PostgreSQL обращается к системным каталогам

• Увеличивается конкуренция за pg_index, pg_class

• Особенно заметно при многих одновременных соединениях

4. CPU overhead

• Обработка индекса требует больше CPU операций

• Bitmap Index Scan + Bitmap Heap Scan сложнее чем простой Seq Scan

• При росте соединений CPU становится узким местом