Привет всем, есть немного глупый теоретический вопрос На вход на бэкенд

Question

Привет всем, есть немного глупый теоретический вопрос На вход на бэкенд

(вне базы) прилетает сет айдишников которые надо проверить на наличие в базе

Я могу сделать это одним запросом, который будет делать что-то вроде select * from UNNEST(ARRAY[*прилетевшие ко мне идентификаторы*]) потом заджоиниться на нужную таблицу левым джоином и выдать результат, так я успешно получу какие айдишники из присланного сета в таблице есть, а каких нет

Но исходный сет айдишников может быть "условно" большим (допустим 10к записей) и вместо одного запроса в базу данных можно послать несколько параллельных запросов

Я бы, конечно, послал один большой, но может ли несколько параллельных запросов быть быстрее в таком случае? Извиняюсь за то что очень пространно спрашиваю

#backend #devops #pgsql #programming #russian

0

17.11.2021

8 ответов

18 просмотров

Egor Gusarenko Автор вопроса

Alexey Bulgakov
10к это не много

Да, поэтому и вопрос скорее теоретический, в плане много ли это в рамках сгенерированого запроса, т е это банально прорва текста

0

17.11.2021

Warstone

"SELECT id FROM table WHERE id IN (" . join(", ", map { $dbh->quote($_) } @ids) . ")" Пока количество id меньше 10К это будет быстрее чем джойнить. Так народ занимается микрооптимизациями.

0

17.11.2021

central hardware

а сам планировщик не догадается распаралелить?

0

17.11.2021

Alexey Bulgakov

Egor Gusarenko
Да, поэтому и вопрос скорее теоретический, в плане...

сделайте стресс тест, что бы определить границы коллекции и дальше limit

0

17.11.2021

Egor Gusarenko Автор вопроса

central hardware
а сам планировщик не догадается распаралелить?

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

0

17.11.2021

Egor Gusarenko Автор вопроса

Warstone
"SELECT id FROM table WHERE id IN (" . join(", ", ...

Выглядит круто, спасибо!

0

17.11.2021

Konstantin Knizhnik

Стратегии тут по существу две: либо использовать индекс, либо нет (делать последовательный поиск и проверять ID-шник на присутствие в заданном множестве). JOIN с использованием nested loop - это разновидность первой стратегии. А вот HASH JOIN - второй. IN clause может как использовать index merge, так и последовательный поиск. Что выгоднее зависит от размеров таблички и множества ID-шиков. А также размера записи (соотношение размера таблички и индекса). Последовательный поиск постгрес ещё умеет параллелить...

0

17.11.2021

Alexey Bulgakov · Accepted Answer

Alexey Bulgakov

10к это не много

0

17.11.2021

172 похожих чатов

Привет всем, есть немного глупый теоретический вопрос На вход на бэкенд

8 ответов

Похожие вопросы