SELECT
	main.*,
	CASE
		WHEN mod(number, 3) = 1 THEN 111
		WHEN mod(number, 3) = 2 THEN 222
		ELSE 333
	END AS manager
FROM
(
	SELECT
		m1.id,
		COUNT(m2.id) AS number
	FROM
		main_training AS m1
	INNER JOIN
		main_training AS m2
	ON
		m1.id >= m2.id
	WHERE
		m1.id IN (1, 2, 3, 5, 15, 20, 40) AND
		m2.id IN (1, 2, 3, 5, 15, 20, 40)
	GROUP BY
		m1.id
	ORDER by
		number
) AS main;

Основная проблема – пронумеровать последовательно все подпадающие под выборку строки. Делается это при помощи INNER JOIN на ту же таблицу. Условие ON m1.id >= m2.id и группировка по m1.id дают в COUNT(m2.id) порядковый номер (таблица m2 джойнится к m1 столько раз, сколько в m2 есть удовлетворяющих условию строк с id меньше m1.id).
После этого на основе модуля от деления порядкового номера на 3 определяем менеджера, которого назначим для сделки.

UPD:
Нашёл (вспомнил) формулу для аггрегирования значений:

formula for running aggregates

SELECT
	x1.key,
	x1.some_column,
	AGGREGATE_FN(x2.some_column) AS running_aggregate
FROM x AS x1
INNER JOIN x AS x2
ON x1.key >= x2.key
GROUP BY x1.key;

Формула взята из доклада Jay Pipes.

INSERT INTO table (columns) VALUES (values) ON DUPLICATE KEY UPDATE column1=value1, column2=value2

Это очень удобно тогда, когда нужно вставить только те данные, которых в таблице нет (при этом в апдейте указывается уже существующее значение поля).
В postgresql такого, к сожалению, нет.
Но подобное поведение можно сэмулировать несколькими способами. Два самых интересных:

1. Создать правило

 CREATE OR REPLACE RULE "insert_ignore_mytable" AS
     ON INSERT TO
          "mytable"
     WHERE EXISTS
          ( SELECT 1 FROM "mytable" WHERE id = NEW.id )
     DO INSTEAD NOTHING;

Этот способ удобен тем, что его нужно написать только один раз, и при любой вставке данных с уже существующим ключом выполнение работы продолжится, а самой вставки не произойдёт. Неудобен тем, что выполняется селект, да и вообще это по сути триггер, делающий лишнюю работу до вставки.
2. Обработать исключение

BEGIN
     INSERT INTO db(a,b) VALUES (key, data);
EXCEPTION WHEN unique_violation THEN
      -- смотрим, улыбаемся
END;

Удобен тем, что не надо затрагивать таблицу, т.е. другие запросы пойдут как обычно. Неудобен тем, что его приходится использовать внутри хранимых процедур.

EXPLAIN SELECT * FROM CUSTOMER;
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on customer  (cost=0.00..60.48 rows=2048 width=107)
(1 row)

Это означает, что оптимизатор решил произвести последовательное чтение записей из таблицы. Он также оценил,что первая строка будет выведена через 0.00, а все – через 60.48. При этом будет возвращено 2048 строк средней длиной 107 байт.
EXPLAIN не запускает сам запрос, это лишь оценка. Для получения точных результатов нужно запустить EXPLAIN ANALYZE:

EXPLAIN ANALYZE SELECT * FROM CUSTOMER;
                                                 QUERY PLAN
------------------------------------------------------------------------------------------------------------
 Seq Scan on customer  (cost=0.00..60.48 rows=2048 width=107) (actual time=0.033..6.577 rows=2048 loops=1)
 Total runtime: 7.924 ms
(2 rows)

Теперь появился второй набор данных: реальное время, затраченное на выполнение последовательного чтения, реальное число строк и количество повторов чтения этих строк (про повторы позже). Также появилась информация о полном времени выполнения запроса.
Можно заметить, что числа в реальном времени не очень то соответствуют предсказанным. Это потому, что оценка измеряется не во времени, а в специальных единицах. Одна единица равна времени, затраченному на последовательное чтение одной страницы с диска.
Но это слишком скучный запрос, перейдём к более интересным.

EXPLAIN SELECT * FROM customer ORDER BY city;
                             QUERY PLAN
--------------------------------------------------------------------
 Sort  (cost=173.12..178.24 rows=2048 width=107)
   Sort Key: city
   ->  Seq Scan on customer  (cost=0.00..60.48 rows=2048 width=107)

Теперь план запроса включает 2 шага: сортировку и последовательное чтение. Хотя это и кажется нелогичным, запрос выполняется снизу вверх (если смотреть на план), т.е. результат последовательного чтения подаётся на вход оператору сортировки (оператор сортировки использует результаты последовательного чтения как входные данные).
Если взглянуть на шаг сортировки, можно заметить, что оптимизатор говорит, по какому полю проводится сортировка («Sort Key»). Разные виды обработки могут выводить дополнительную информацию вроде этой. Также стоит обратить внимание на то, что затраты на вывод первой строки оператором сортировки очень велики, они почти равны затратам на вывод всех столбцов. Это из-за того, что сначала он должен отсортировать все строки, что и занимает большую часть времени.
Если шагов выполнения запроса несколько, то показываемые затраты на шаг содержат не только затраты на выполнение этого шага, но и всех шагов ниже. В нашем примере затраты на шаг сортировки равны 173.12-60.48 для вывода первого результата, и 178.24-60.48 для вывода всех результатов. 60.48 вычитается из-за того, что сортировке необходимо получить все данные от последовательного чтения, прежде чем вернуть хоть что-то. В общем, когда видите очень похожие числа в затратах вывода первого и всех результатов, это означает, что операции требуются все данные предыдущих операций.

Теперь рассмотрим ещё более интересный пример:

EXPLAIN ANALYZE SELECT * FROM customer JOIN contact USING (last_name);
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------
 Hash Join  (cost=1.02..92.23 rows=2048 width=351) (actual time=1.366..58.684 rows=4096 loops=1)
   Hash Cond: (("outer".last_name)::text = ("inner".last_name)::text)
   ->  Seq Scan on customer  (cost=0.00..60.48 rows=2048 width=107) (actual time=0.079..21.658 rows=2048 loops=1)
   ->  Hash  (cost=1.02..1.02 rows=2 width=287) (actual time=0.146..0.146 rows=2 loops=1)
         ->  Seq Scan on contact  (cost=0.00..1.02 rows=2 width=287) (actual time=0.074..0.088 rows=2 loops=1)
 Total runtime: 62.233 ms

Наконец-то что-то похожее на настоящий запрос. Обратите внимание на отступы. Они используются, чтобы показать, что результаты одних шагов используются в качестве входных данных для других. В нашем примере можно увидеть, что hash join принимает на вход результаты выполнения последовательного чтения и hash-операции. Последняя, в свою очередь, сама работает с результатами последовательного чтения. Заметьте, что hash-операция имеет одинаковые затраты на вывод первого и всех результатов – ей нужны все результаты до того, как вернуть что-либо. В этом плане интересно то, что затраты на вывод первого результата hash join зависит от суммарных затрат hash-операции, но начинается одновременно с последовательным чтением таблицы customer. Это потому, что hash join может возвращать результаты сразу, как только получит первый результат от обеих операций, дающих ему данные на вход.

Вернёмся к объяснению того, что такое повторы или циклы (loops), для этого рассмотрим пример:

->  Nested Loop  (cost=5.64..14.71 rows=1 width=140) (actual time=18.983..19.481 rows=4 loops=1)
               ->  Hash Join  (cost=5.64..8.82 rows=1 width=72) (actual time=18.876..19.212 rows=4 loops=1)
               ->  Index Scan using pg_class_oid_index on pg_class i  (cost=0.00..5.88 rows=1 width=72) (actual time=0.051..0.055 rows=1 loops=4)

Вложенный цикл – это то, что хорошо знакомо программистам, пишущим на процедурных языках; это что-то вроде:

for each row in input_a
    for each row in input_b
        do something
    next
next

Если в input_a 4 элемента, то внутренний цикл ( по input_b) будет выполнен 4 раза. Это именно то, о чём нам говорит оптимизатор в примере выше. Если умножить 0.055 на 4, то получится чуть меньше, чем разница между общим временем выполнения hash join’а и общим временем выполнения вложенного цикла (остаток времени скорее всего пошёл на накладные расходы, связанные с вычислением всего этого).

Что же это означает на практике? Обычно запрос запускают с EXPLAIN, пытаясь улучшить производительность. Ключом к этому является поиск шага, который занимает большую часть времени (а потом надо попытаться переписать медленную часть или весь запрос). Давайте взглянем на следующий пример и попытаемся найти проблемный шаг. (Этот запрос может запустить каждый и получит такой же результат).

EXPLAIN ANALYZE SELECT * FROM pg_indexes WHERE tablename='pg_constraint';
                                                 QUERY PLAN
---------------------------------------------------------------------------------------------------------------
Nested Loop Left Join  (cost=5.64..16.89 rows=1 width=260) (actual time=19.552..20.530 rows=4 loops=1)
  Join Filter: ("inner".oid = "outer".reltablespace)
  ->  Nested Loop Left Join  (cost=5.64..15.84 rows=1 width=200) (actual time=19.313..20.035 rows=4 loops=1)
        Join Filter: ("inner".oid = "outer".relnamespace)
        ->  Nested Loop  (cost=5.64..14.71 rows=1 width=140) (actual time=18.983..19.481 rows=4 loops=1)
              ->  Hash Join  (cost=5.64..8.82 rows=1 width=72) (actual time=18.876..19.212 rows=4 loops=1)
                    Hash Cond: ("outer".indrelid = "inner".oid)
                    ->  Seq Scan on pg_index x  (cost=0.00..2.78 rows=78 width=8) (actual time=0.037..0.296 rows=80 loops=1)
                    ->  Hash  (cost=5.63..5.63 rows=1 width=72) (actual time=18.577..18.577 rows=1 loops=1)
                          ->  Index Scan using pg_class_relname_nsp_index on pg_class c (cost=0.00..5.63 rows=1 width=72) (actual time=18.391..18.464 rows=1 loops=1)
                                Index Cond: (relname = 'pg_constraint'::name)
                                Filter: (relkind = 'r'::"char")
              ->  Index Scan using pg_class_oid_index on pg_class i  (cost=0.00..5.88 rows=1 width=72) (actual time=0.051..0.055 rows=1 loops=4)
                    Index Cond: (i.oid = "outer".indexrelid)
                    Filter: (relkind = 'i'::"char")
        ->  Seq Scan on pg_namespace n  (cost=0.00..1.06 rows=6 width=68) (actual time=0.014..0.045 rows=6 loops=4)
  ->  Seq Scan on pg_tablespace t  (cost=0.00..1.02 rows=2 width=68) (actual time=0.010..0.018 rows=2 loops=4)
Total runtime: 65.294 ms

Вложенный цикл имеет самое большое время выполнения – 20.035мс. Он, в свою очередь, использует результаты другого вложенного цикла и последовательного чтения, и уже этот вложенный цикл – самый долгий (19.481 мс).
Следовательно, сейчас «путь» к «дорогому» шагу следующий:

Nested Loop Left Join  (cost=5.64..16.89 rows=1 width=260) (actual time=19.552..20.530 rows=4 loops=1)
   Join Filter: ("inner".oid = "outer".reltablespace)
   ->  Nested Loop Left Join  (cost=5.64..15.84 rows=1 width=200) (actual time=19.313..20.035 rows=4 loops=1)
         Join Filter: ("inner".oid = "outer".relnamespace)
         ->  Nested Loop  (cost=5.64..14.71 rows=1 width=140) (actual time=18.983..19.481 rows=4 loops=1)

В этом примере эти шаги расположены последовательно, но это не всегда так.
Нижний вложенный цикл берёт данные отсюда:

               ->  Hash Join  (cost=5.64..8.82 rows=1 width=72) (actual time=18.876..19.212 rows=4 loops=1)
                     Hash Cond: ("outer".indrelid = "inner".oid)
                     ->  Seq Scan on pg_index x  (cost=0.00..2.78 rows=78 width=8) (actual time=0.037..0.296 rows=80 loops=1)
                     ->  Hash  (cost=5.63..5.63 rows=1 width=72) (actual time=18.577..18.577 rows=1 loops=1)
                           ->  Index Scan using pg_class_relname_nsp_index on pg_class (cost=0.00..5.63 rows=1 width=72) (actual time=18.391..18.464 rows=1 loops=1)
                                 Index Cond: (relname = 'pg_constraint'::name)
                                 Filter: (relkind = 'r'::"char")
               ->  Index Scan using pg_class_oid_index on pg_class i  (cost=0.00..5.88 rows=1 width=72) (actual time=0.051..0.055 rows=1 loops=4)
                     Index Cond: (i.oid = "outer".indexrelid)
                     Filter: (relkind = 'i'::"char")

Заметим, что большую часть времени занимает hash join. Он берёт данные из последовательного чтения и hash-операции. Эта hash-операция занимает большую часть времени:

                     ->  Hash  (cost=5.63..5.63 rows=1 width=72) (actual time=18.577..18.577 rows=1 loops=1)
                           ->  Index Scan using pg_class_relname_nsp_index on pg_class c
                               (cost=0.00..5.63 rows=1 width=72) (actual time=18.391..18.464 rows=1 loops=1)
                                 Index Cond: (relname = 'pg_constraint'::name)
                                 Filter: (relkind = 'r'::"char")

Мы наконец нашли самую дорогую часть запроса: сканирование индекса pg_class_relname_nsp_index. К сожалению, практически невозможно ускорить сканирование индекса для поиска одной строки. Но и занимает оно всего 18.464 мс, вряд ли когда-нибудь понадобится настолько улучшать производительность.
Ещё одно замечание: затраты на EXPLAIN ANALYZE достаточно значительны. Они могут занимать до 30% времени выполнения запроса. Поэтому EXPLAIN – это инструмент для измерения относительной производительности, а не абсолютной.

Оригинал статьи – Introduction to VACUUM, ANALYZE, EXPLAIN, and COUNT

WITH RECURSIVE stat_( inputdate ) AS (
		SELECT COUNT(*) AS total, curdate
		FROM account
		WHERE expired > inputdate AND inputdate = NOW() - INTERVAL '1 MONTH'
	UNION ALL
		SELECT COUNT(*) AS total, ( inputdate + INTERVAL '1 DAY' ) AS curdate
		FROM stat_, account
		WHERE expired > curdate AND curdate = NOW() + INTERVAL '1 MONTH'

)
SELECT * FROM stat_

Очень простой способ – создаём виртуалную таблицу:

 SELECT 'now'::text::date + s.a AS day, account.id, count(account.id) AS count
   FROM generate_series((-120), 0) s(a)