DPH3Тестирую на разных сценариях очередь.
Есть две таблицы: queue, events
Запрос на получение очередного события:


индекс events(queue)

В таблице queue 2 записи, условию не удовлетворяет ни одна
В таблице events 2 000 000 записей, все с q.queue=e.queue
При запросе PG делает loop join с перебором по events, что занимает 2 секунды, хотя кажется логичнее делать по queue, с выбором подходящего из events по индексу.

Что я делаю не так, как ускорить такой запрос?

(Аналогичная проблема возникает, когда под условие подходит только одна запись в events, но с максимальным id - тоже приходится сканировать всю таблицу events по первичному ключу, что долго. Понятно, что если подходит запись в event с минимальным id, то все отрабатывает мгновенно и вообще в events обычно мало записей и подходящие находятся сразу, я в основном проверяю corner cases, но реальные).

Заранее спасибо.

А если сделать analyze queue; - план не меняется?

--
Maxim Boguk
www.postgresql-consulting.ru

DPH3Maxim Boguk,

Нет, не меняется, увы (

1)а что говори explain analyze на этот запрос?
2)сколько уникальных queue а таблице events ?


PS: вообще привыкайте всегда все такие вопросы сопровождать результатом explain analyze.


--
Maxim Boguk
www.postgresql-consulting.ru

DPH3Maxim Boguk,

1. explain analyze:

"Limit (cost=0.43..0.54 rows=1 width=41) (actual time=1781.399..1781.399 rows=1 loops=1)"
" -> LockRows (cost=0.43..137154.11 rows=1234680 width=41) (actual time=1781.399..1781.399 rows=1 loops=1)"
" -> Nested Loop (cost=0.43..124807.31 rows=1234680 width=41) (actual time=1781.394..1781.394 rows=1 loops=1)"
" Join Filter: ((q.queue)::text = (e.queue)::text)"
" Rows Removed by Join Filter: 2469359"
" -> Index Scan using events_pkey on wq_events e (cost=0.43..87765.87 rows=2469360 width=35) (actual time=0.038..1263.381 rows=2469360 loops=1)"
" -> Materialize (cost=0.00..1.04 rows=1 width=15) (actual time=0.000..0.000 rows=1 loops=2469360)"
" -> Seq Scan on queue q (cost=0.00..1.03 rows=1 width=15) (actual time=0.005..0.005 rows=1 loops=1)"
" Filter: (((state)::text = 'RUNNING'::text))"
" Rows Removed by Filter: 1"
"Planning time: 0.606 ms"
"Execution time: 1781.447 ms"

2. В данный момент два queue в events, в одном два значения, в другом - все остальные.

1)Вы же написали что "В таблице queue 2 записи, условию не удовлетворяет ни одна" а у вас одна есть.
2)Нельзя построить единый план который бы работал нормально в вашей структуре данных.
База предполагает что e.queue более менее поровну распределены по wq_events
Поэтому база вполне честно считает что она быстро найдет нужную ей запись, а то что у вас данные сильно неровные - не делайте такие данные.

Любой план будет плохо работать на corner cases и ничего вы с этим не сделаете.
База из неких средне-нормальных вариантов план подбирает.

--
Maxim Boguk
www.postgresql-consulting.ru

qwwqесли кваеев всегда мало (что модельно скорее всего так и есть), то нужен индекс (кваее,ивент) и переписать запрос на лейтерал по 50 записей из каждой кваее, с последующим фильтром 50 из отобранных вдоль ивент.

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

PS: автору топика - возьмите PGQ и не извращайтесь. Я пока не видел НИ ОДНОЙ нормальной самописной очереди на Postgres (а посмотрел я их много).

--
Maxim Boguk
www.postgresql-consulting.ru

[quot DPH3][quot Maxim Boguk]
PS: автору топика - возьмите PGQ и не извращайтесь. Я пока не видел НИ ОДНОЙ нормальной самописной очереди на Postgres (а посмотрел я их много).
пропущено...

Вот из-за case corners нормально ваше решение в режиме 100 очередей новых в секунду - работать никогда не будет.
Вообще постоянное создание и drop очередей - это признак того что архитектурно что то не то делают.
Т.е. pgq такой какой он есть именно для того чтобы работать быстро всегда (и таки да он работает быстро), а для этого в таблицах очереди не должно быть никаких странных аномалий с данными.

--
Maxim Boguk
www.postgresql-consulting.ru