Даже опытные разработчики иногда ошибаются с оконными функциями PostgreSQL.
Есть таблица событий:
CREATE TABLE events (
id INT PRIMARY KEY,
user_id INT,
ts TIMESTAMP
);
INSERT INTO events VALUES
(1, 10, '2026-01-01 10:00'),
(2, 10, '2026-01-01 10:05'),
(3, 10, '2026-01-01 10:05'),
(4, 10, '2026-01-01 10:20');
Выполняем запрос:
SELECT
id,
COUNT(*) OVER (
PARTITION BY user_id
ORDER BY ts
) AS cnt
FROM events
ORDER BY id;
Что вернёт PostgreSQL?
А)
1, 2, 3, 4Б)
1, 3, 3, 4В)
4, 4, 4, 4Г)
1, 2, 2, 4Правильный ответ:
По умолчанию PostgreSQL использует оконную рамку:
```sql
RANGE BETWEEN UNBOUNDED PRECEDING
AND CURRENT ROW
```
При
RANGEts10:05cnt = 3Чтобы получить обычный накопительный счётчик, нужно явно указать
ROWS```sql
SELECT
id,
COUNT(*) OVER (
PARTITION BY user_id
ORDER BY ts, id
ROWS BETWEEN UNBOUNDED PRECEDING
AND CURRENT ROW
) AS cnt
FROM events
ORDER BY id;
```
Теперь результат:
1, 2, 3, 4Подвох:
COUNT(*) OVER (ORDER BY ...)Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤5🔥4
SQL-задача с подвохом: найдите пользователей, которые вернулись после 30 дней молчания
Представьте, что вы анализируете активность пользователей сервиса. Нужно найти тех, кто вернулся после длительного перерыва.
Есть таблица PostgreSQL:
Задача: для каждого пользователя найти все даты возвращения после 30 полных календарных дней без активности.
Ожидаемый результат:
| user_id | return_date |
|---|---|
| 1 | 2026-11-01 |
| 3 | 2026-11-05 |
Условия: несколько событий в один день считаются одной активностью. День последней активности и день возвращения в период молчания не входят. Например, между 1 октября и 31 октября только 29 полных дней без активности, а между 1 октября и 1 ноября уже 30.
Ограничение: решите задачу одним SQL-запросом, без процедур, временных таблиц и циклов.
На первый взгляд достаточно
Как бы вы решили эту задачу на PostgreSQL?
Представьте, что вы анализируете активность пользователей сервиса. Нужно найти тех, кто вернулся после длительного перерыва.
Есть таблица PostgreSQL:
CREATE TABLE events (
user_id INT,
event_time TIMESTAMP
);
INSERT INTO events VALUES
(1, '2026-10-01 10:00'),
(1, '2026-10-01 12:00'),
(1, '2026-11-01 09:00'),
(1, '2026-11-02 14:00'),
(2, '2026-10-01 10:00'),
(2, '2026-10-31 10:00'),
(3, '2026-09-01 10:00'),
(3, '2026-11-05 10:00'),
(3, '2026-11-05 11:00');
Задача: для каждого пользователя найти все даты возвращения после 30 полных календарных дней без активности.
Ожидаемый результат:
| user_id | return_date |
|---|---|
| 1 | 2026-11-01 |
| 3 | 2026-11-05 |
Условия: несколько событий в один день считаются одной активностью. День последней активности и день возвращения в период молчания не входят. Например, между 1 октября и 31 октября только 29 полных дней без активности, а между 1 октября и 1 ноября уже 30.
Ограничение: решите задачу одним SQL-запросом, без процедур, временных таблиц и циклов.
На первый взгляд достаточно
LAG(), но если не учесть дубли событий и границы календарных дней, результат окажется неправильным.Как бы вы решили эту задачу на PostgreSQL?
👍7🔥6❤2🥰1
RAG без векторной базы: PageIndex набрал 40 тысяч звёзд на GitHub
PageIndex предлагает другой подход к поиску информации в документах. Вместо embeddings, разбиения текста на чанки и векторного поиска используется иерархический индекс и рассуждения LLM.
Система строит дерево разделов документа, а затем модель последовательно выбирает нужные ветки и находит ответ с указанием источника.
Такой подход особенно полезен для больших PDF, финансовых отчётов, юридических документов и технической документации, где одного семантического сходства недостаточно.
Результаты разработчиков:
98,7% точности на FinanceBench.
До 97% экономии токенов при ответах на вопросы по документам с использованием Page Search API.
В 16,6 раза дешевле, чем передавать модели целый PDF на 420 страниц при каждом запросе, в одном из сравнительных тестов.
Это результаты собственных бенчмарков проекта, поэтому для конкретной RAG-системы их стоит перепроверять.
Есть Python SDK, локальная индексация PDF и интеграции с ИИ-агентами. Лицензия MIT.
PageIndex особенно интересно попробовать там, где обычный vector RAG теряет контекст между разделами длинного документа.
GitHub: https://github.com/VectifyAI/PageIndex
PageIndex предлагает другой подход к поиску информации в документах. Вместо embeddings, разбиения текста на чанки и векторного поиска используется иерархический индекс и рассуждения LLM.
Система строит дерево разделов документа, а затем модель последовательно выбирает нужные ветки и находит ответ с указанием источника.
Такой подход особенно полезен для больших PDF, финансовых отчётов, юридических документов и технической документации, где одного семантического сходства недостаточно.
Результаты разработчиков:
98,7% точности на FinanceBench.
До 97% экономии токенов при ответах на вопросы по документам с использованием Page Search API.
В 16,6 раза дешевле, чем передавать модели целый PDF на 420 страниц при каждом запросе, в одном из сравнительных тестов.
Это результаты собственных бенчмарков проекта, поэтому для конкретной RAG-системы их стоит перепроверять.
Есть Python SDK, локальная индексация PDF и интеграции с ИИ-агентами. Лицензия MIT.
pip install -U pageindex
PageIndex особенно интересно попробовать там, где обычный vector RAG теряет контекст между разделами длинного документа.
GitHub: https://github.com/VectifyAI/PageIndex
❤9🔥3