Подходит ли платформа для начинающих без опыта работы?

Да, курсы разбиты по уровням: Junior, Middle, Senior. Начинающие могут стартовать с базовых тем Python, Docker и алгоритмов и постепенно двигаться к более сложным темам.

Как быстро можно подготовиться к собеседованию на позицию Junior разработчика?

При занятиях 1–2 часа в день — от 2 до 4 недель на основные темы. Платформа анализирует слабые места по результатам квизов и строит персональный план подготовки.

Какие технологии охватывает платформа?

Python, FastAPI, Django, Docker, алгоритмы и структуры данных, Agile/Scrum, SQL, CI/CD, системный дизайн, код-ревью и более 50 других тем для разработчиков.

Платформа бесплатная?

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

Как платформа помогает найти работу программистом?

Платформа даёт фундаментальные знания, которые проверяют на технических собеседованиях: алгоритмы, архитектура, фреймворки. Мок-интервью имитирует реальное собеседование. Система прогресса показывает, какие темы нужно подтянуть перед собеседованием.

partial_index

Частичные и условные индексы

Индексы с WHERE-условием: экономия места и оптимизация специфичных запросов.

Частичные и условные индексы

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

1. Что такое частичный индекс

Частичный индекс (partial index) — это индекс с WHERE-условием, содержащий только строки, удовлетворяющие этому условию.

-- Полный индекс (все строки)
CREATE INDEX idx_users_email ON users(email);

-- Частичный индекс (только активные пользователи)
CREATE INDEX idx_users_active_email ON users(email) WHERE active = true;

Преимущества

Преимущество	Описание
Меньший размер	Индекс содержит только часть строк
Быстрее поиск	Меньше записей для сканирования
Быстрее вставка	Индекс обновляется только для подходящих строк
Специфичная оптимизация	Для редких, но важных запросов

2. Синтаксис

CREATE INDEX index_name ON table_name (column) WHERE predicate;

Примеры

-- Индекс для активных пользователей
CREATE INDEX idx_active_users ON users(email) WHERE active = true;

-- Индекс для заказов со статусом 'pending'
CREATE INDEX idx_pending_orders ON orders(user_id, created_at) 
WHERE status = 'pending';

-- Индекс для больших заказов
CREATE INDEX idx_large_orders ON orders(user_id) WHERE amount > 10000;

-- Индекс для не удалённых записей
CREATE INDEX idx_not_deleted ON documents(title) WHERE deleted_at IS NULL;

3. Когда использовать частичные индексы

3.1. Редкие значения

-- Статусы заказов: 'pending' (5%), 'completed' (70%), 'cancelled' (25%)
CREATE INDEX idx_pending_orders ON orders(user_id, created_at) 
WHERE status = 'pending';

Почему:

status = 'pending' — только 5% строк
Полный индекс был бы в 20 раз больше
Запросы к pending-заказам частые и критичные

3.2. Активные записи

-- Таблица с мягким удалением (soft delete)
CREATE TABLE documents (
    id BIGSERIAL,
    title VARCHAR(255),
    content TEXT,
    deleted_at TIMESTAMP
);

-- Индекс только для активных документов
CREATE INDEX idx_active_docs ON documents(title, created_at) 
WHERE deleted_at IS NULL;

Почему:

Удалённые документы не нужны в поиске
Индекс на 90% меньше (если 90% удалено)
Поиск быстрее

3.3. Специфичные диапазоны

-- Индекс для премиум-заказов (amount > 10000)
CREATE INDEX idx_premium_orders ON orders(user_id, amount) 
WHERE amount > 10000;

Почему:

Премиум-заказы требуют особого внимания
Их мало (например, 1%)
Частые отчёты по премиум-сегменту

3.4. Уникальность для подмножества

-- Уникальный email только для активных пользователей
CREATE UNIQUE INDEX idx_unique_active_email ON users(email) 
WHERE active = true;

Результат:

Активные пользователи не могут иметь дубликаты email
Неактивные могут иметь любые email (даже дубликаты активных)
Гибкое ограничение без триггеров

4. Когда частичный индекс НЕ используется

Оптимизатор использует частичный индекс, только если запрос логически подразумевает предикат.

4.1. Пример использования

CREATE INDEX idx_pending ON orders(user_id) WHERE status = 'pending';

-- ✅ Использует индекс
SELECT * FROM orders WHERE status = 'pending' AND user_id = 123;

-- ✅ Использует индекс (status IN включает 'pending')
SELECT * FROM orders WHERE status IN ('pending', 'completed') AND user_id = 123;
-- Но может не использовать, если селективность низкая

-- ❌ НЕ использует индекс
SELECT * FROM orders WHERE user_id = 123;
-- Нет условия на status

-- ❌ НЕ использует индекс
SELECT * FROM orders WHERE status = 'completed' AND user_id = 123;
-- Предикат не выполняется (completed ≠ pending)

4.2. Логическое следование

Предикат может быть сложным:

CREATE INDEX idx_recent_active ON orders(user_id, created_at) 
WHERE status = 'pending' AND created_at > '2026-01-01';

-- ✅ Использует индекс
SELECT * FROM orders 
WHERE status = 'pending' 
  AND created_at > '2026-02-01'  -- Подмножество предиката
  AND user_id = 123;

-- ❌ НЕ использует индекс
SELECT * FROM orders 
WHERE status = 'pending' 
  AND created_at > '2025-01-01'  -- Более широкий диапазон
  AND user_id = 123;

5. Сравнение: полный vs частичный индекс

5.1. Размер

-- Полный индекс
CREATE INDEX idx_all_orders ON orders(user_id, status);
-- Размер: 50 MB

-- Частичный индекс
CREATE INDEX idx_pending_orders ON orders(user_id) WHERE status = 'pending';
-- Размер: 2 MB (только 5% строк)

5.2. Производительность поиска

EXPLAIN ANALYZE 
SELECT * FROM orders WHERE status = 'pending' AND user_id = 123;

Полный индекс:

Index Scan using idx_all_orders on orders
  Index Cond: (user_id = 123 AND status = 'pending')
  Execution Time: 0.5 ms

Частичный индекс:

Index Scan using idx_pending_orders on orders
  Index Cond: (user_id = 123)
  Execution Time: 0.1 ms

Ускорение: в 5 раз (меньше записей для сканирования)

5.3. Производительность вставки

INSERT INTO orders (user_id, status, amount) VALUES (456, 'completed', 100);

Полный индекс:

Обновляется всегда

Частичный индекс:

НЕ обновляется (status = 'completed' ≠ 'pending')
Вставка быстрее

6. Частичные индексы для уникальности

6.1. Уникальность с условием

-- Один активный заказ на пользователя в момент времени
CREATE UNIQUE INDEX idx_one_active_per_user ON orders(user_id) 
WHERE status IN ('pending', 'processing');

Результат:

У пользователя может быть много заказов со статусом 'completed'
Но только один 'pending' или 'processing'

6.2. Уникальность с NULL

-- Уникальный slug для опубликованных статей
CREATE UNIQUE INDEX idx_published_slug ON articles(slug) 
WHERE published = true;

-- Черновики могут иметь дубликаты slug
INSERT INTO articles (slug, published) VALUES ('my-post', false);  -- ✅
INSERT INTO articles (slug, published) VALUES ('my-post', false);  -- ✅
INSERT INTO articles (slug, published) VALUES ('my-post', true);   -- ✅ (первый published)
INSERT INTO articles (slug, published) VALUES ('my-post', true);   -- ❌ Ошибка

7. Комбинация с другими типами индексов

7.1. Частичный + составной

CREATE INDEX idx_composite_partial ON orders(user_id, created_at DESC) 
WHERE status = 'pending';

7.2. Частичный + покрывающий

CREATE INDEX idx_covering_partial ON orders(user_id) 
INCLUDE (created_at, amount) 
WHERE status = 'pending';

7.3. Частичный + выражение

CREATE INDEX idx_lower_email_active ON users(LOWER(email)) 
WHERE active = true;

8. Диагностика

8.1. Проверка размера

SELECT 
    indexname,
    pg_size_pretty(pg_relation_size(indexname::regclass)) as size,
    indexdef
FROM pg_indexes
WHERE tablename = 'orders'
  AND indexdef LIKE '%WHERE%';

8.2. Проверка использования

SELECT 
    indexrelname,
    idx_scan as scans,
    idx_tup_read as tuples_read,
    pg_size_pretty(pg_relation_size(indexrelid)) as size
FROM pg_stat_user_indexes
WHERE relname = 'orders';

8.3. Проверка предиката

SELECT 
    indexname,
    pg_get_indexdef(indexrelid) as definition
FROM pg_indexes
WHERE schemaname = 'public'
  AND indexdef LIKE '%WHERE%';

9. Типичные ошибки

9.1. Избыточные индексы

-- ❌ Плохо: дублирование индекса
CREATE INDEX idx_all ON orders(user_id);
CREATE INDEX idx_pending ON orders(user_id) WHERE status = 'pending';
-- Второй индекс покрывает подмножество первого, но первый всё ещё нужен для других статусов

-- ✅ Хорошо: только частичный, если запросы только к pending
CREATE INDEX idx_pending ON orders(user_id) WHERE status = 'pending';

9.2. Слишком широкий предикат

-- ❌ Бесполезно: 99% строк подходят
CREATE INDEX idx_mostly_all ON orders(user_id) 
WHERE created_at > '2020-01-01';  -- Почти все записи

-- ✅ Хорошо: 5-10% строк
CREATE INDEX idx_pending ON orders(user_id) 
WHERE status = 'pending';

9.3. Предикат с функцией

-- ❌ Не сработает как ожидается
CREATE INDEX idx_lower_status ON orders(user_id) 
WHERE LOWER(status) = 'pending';

-- Запрос:
SELECT * FROM orders WHERE LOWER(status) = 'pending';  -- ✅ Работает
SELECT * FROM orders WHERE status = 'pending';         -- ❌ НЕ работает!

-- ✅ Правильно
CREATE INDEX idx_status ON orders(user_id) 
WHERE status = 'pending';

9.4. Динамические условия

-- ❌ Предикат должен быть статичным
CREATE INDEX idx_recent ON orders(user_id) 
WHERE created_at > NOW() - INTERVAL '30 days';  -- Ошибка!

-- ✅ Правильно: статичное значение
CREATE INDEX idx_recent ON orders(user_id) 
WHERE created_at > '2026-01-01';

10. Best practices

✅ Делайте

Используйте для редких значений (< 10% строк)
Создавайте для критичных бизнес-запросов
Комбинируйте с составными и покрывающими индексами
Проверяйте размер через pg_relation_size()
Удаляйте, если предикат устарел

❌ Не делайте

Не создавайте для > 30% строк (выгода минимальна)
Не используйте функции в предикате
Не используйте динамические значения (NOW(), CURRENT_DATE)
Не создавайте без анализа реальных запросов
Не забывайте про поддержку предиката в приложении

11. Практические примеры

11.1. Очереди задач

CREATE TABLE tasks (
    id BIGSERIAL,
    queue_name VARCHAR(50),
    status VARCHAR(20),  -- 'pending', 'running', 'completed', 'failed'
    payload JSONB,
    created_at TIMESTAMP
);

-- Индекс только для pending задач (очередь)
CREATE INDEX idx_tasks_pending ON tasks(queue_name, created_at) 
WHERE status = 'pending';

-- Выбор следующей задачи
SELECT * FROM tasks 
WHERE queue_name = 'emails' AND status = 'pending'
ORDER BY created_at ASC
LIMIT 1;

11.2. Многопользовательская система

CREATE TABLE sessions (
    id BIGSERIAL,
    user_id BIGINT,
    is_active BOOLEAN,
    last_seen TIMESTAMP
);

-- Индекс только для активных сессий
CREATE INDEX idx_active_sessions ON sessions(user_id, last_seen) 
WHERE is_active = true;

-- Поиск активных сессий пользователя
SELECT * FROM sessions 
WHERE user_id = 123 AND is_active = true
ORDER BY last_seen DESC;

11.3. Архивные данные

CREATE TABLE events (
    id BIGSERIAL,
    event_type VARCHAR(50),
    event_data JSONB,
    archived BOOLEAN DEFAULT false,
    created_at TIMESTAMP
);

-- Индекс для активных (не архивных) событий
CREATE INDEX idx_active_events ON events(event_type, created_at) 
WHERE archived = false;

-- Отдельный индекс для архива (если нужен доступ)
CREATE INDEX idx_archived_events ON events(event_type, created_at) 
WHERE archived = true;

12. Что дальше?

Уникальность и ограничения — PRIMARY KEY и UNIQUE
Покрывающие индексы — INCLUDE для Index Only Scan
Мониторинг и отладка — диагностика проблем

Ключевые выводы

Частичный индекс = WHERE-условие — содержит только подмножество строк
Экономия места — до 90% меньше для редких значений
Быстрее поиск — меньше записей для сканирования
Быстрее вставка — обновляется только для подходящих строк
Предикат должен быть статичным — никаких NOW() или функций

Проверьте свои знания

Вопросы ещё не добавлены

Вопросы для этой подтемы ещё не добавлены.

Преимущество

Описание

Меньший размер

Индекс содержит только часть строк

Быстрее поиск

Меньше записей для сканирования

Быстрее вставка

Индекс обновляется только для подходящих строк

Специфичная оптимизация

Для редких, но важных запросов