Нормально ли дублирование строк в IN?

Question

[Alex G.]

Анализирую долгие запросы в системе. И в запросе вижу что в IN очень много раз передается одна и таже строка. Подскажите нормально ли это или нет?
Вот пример:

IN (
		'91cbfdc8-5d5d-465e-95a4-3235b8c01d5b'
	,	'8fee99ee-b3fd-49dd-9b48-e51b83597227'
	,	'e04a433b-5b48-40c2-993a-41370b9ebb8a'
	,	'd238ef51-607e-46a5-b86a-ede4482f7f19'
	,	'00000000-0000-0000-0000-000000000000'
	,	'00000000-0000-0000-0000-000000000000'
	,	'f44faafc-cd55-4c5b-b16d-93b6fc966ffb'
	,	'00000000-0000-0000-0000-000000000000'
	,	'00000000-0000-0000-0000-000000000000'
	,	'50e39d87-4fc6-4847-8bad-20847b9ba020'
	,	'7cca016a-80f0-4562-9042-57bb748d5b30'
	,	'00000000-0000-0000-0000-000000000000'
	,	'00000000-0000-0000-0000-000000000000'
	,	'e2dd5bf3-54c8-4846-b158-9c42d09fbc33'
	,	'00000000-0000-0000-0000-000000000000'
	,	'00000000-0000-0000-0000-000000000000'
	,	'69ac657a-0e74-46be-acba-f6bbbbd2bc73'
	,	'00000000-0000-0000-0000-000000000000'
	,	'00000000-0000-0000-0000-000000000000'
	,	'018e582e-5b0e-4e4f-af57-be1e0a468efa'
	,	'00000000-0000-0000-0000-000000000000'
	,	'00000000-0000-0000-0000-000000000000')

Comments

[alexalexes]

Отдельный уточняющий вопрос:
некое_поле in (список значений)
У вас "некое_поле" проиндексировано?

[Everything_is_bad]

Анализирую долгие запросы в системе.

почему ты анализируешь без explain analyze?

[Alex G.]

Everything_is_bad, Почему ты отвечаешь не на поставленный вопрос?

[Alex G.]

alexalexes, То что оно не проиндексировано это я знаю. Получил план с аnalyze.
Вопрос в другом, касающийся формирования запроса.

[Everything_is_bad]

Alex G., потому что это не ответ, а комментарий, разницу понимаешь?

[Alex G.]

Everything_is_bad, Разницу понимаю, не понимаю суть вашего вопроса!

[Everything_is_bad]

Alex G., к тому что ты не там и не так ищешь проблему, тут пофиг на дублирование, главное что показывает explain analyze, например, показал что нет индекса и если для тебя время запроса неприемлемо, добавляешь индекс и всё, проблема решена.

Answer 1

[alexalexes]

Вообще, в in засовывать некий массив данных, который больше по количеству элементов, чем пальцев на руках, самый неоптимальный вариант из все возможных.
Если у вас, действительно, целый массив данных, который нужно применить в запросе, то лучше создать заготовку для временной таблицы в схеме данных, и перед выполнением туда подгружать то, что пригодится для in или уже как подзапрос перепишите с участием временной таблицы.
Временную таблицу можно проиндексировать, и это во время выполнения запроса будет уже лучше работать, чем in.
PS: В разных СУБД по-разному реализуются временные таблицы. У них есть разный уровень времени жизни данных - в течении сессии подключения пользователя, в течении транзакции... Посмотрите, какой вариант можно взять для Postgres - его и используйте.

Comments

[Алексей Уколов]

перед выполнением туда подгружать то, что пригодится для in

В смысле - создать временную таблицу, её заполнить этим списком из вопроса, а потом выбирать через WHERE `col` IN (SELECT `val` FROM `tmp`)?

[elderl]

Алексей Уколов, JOIN

[Akina]

elderl, если поле, по которому выполняется фильтрация, не является уникальным, то JOIN даст неэквивалентный запрос.

[elderl]

Akina, Если неуникальность слева, то тот же набор данных. А уникальность справа обеспечивается при создании временного набора данных.
Если я ошибаюсь, то можете привести пример?

[Akina]

elderl, речь именно о неуникальности справа. Вы, к сожалению, не оговорили необходимость уникальности во временной таблице в ответе. Да, если уникальность будет обеспечена, JOIN эквивалентен. Иначе следует использовать WHERE EXISTS.

[Vitsliputsli]

alexalexes,

в in засовывать некий массив данных, который больше по количеству элементов, чем пальцев на руках, самый неоптимальный вариант из все возможных.

для 11 значений временная таблица не будет более быстрым решением. Сам запрос наверное, но будут же еще и расходы на создание таблицы, наполнение ее данными, удаление таблицы. А т.к. это все разными запросами, то плюс сетевой лаг. Не говоря уже о том, что вместо одного понятного запроса у нас целая вереница, что когда завтра подключим СУБД как slave, свято веря, что мы только читаем, упадем на этом запросе.
В общем, я бы не стал играть с временными таблицами без прям хороших показаний для этого. А выбрать 11 значений очень слабый аргумент для этого.

Answer 2

[ky0]

Надо смотреть, как формируется этот список. В целом, это неоптимально - но допустимо.

Comments

[Alex G.]

Вроде как при планировании запроса PG должна бороться с такими дублями. Но вот насколько это правда и как проверить не знаю.

[Akina]

Вроде как при планировании запроса PG должна бороться с такими дублями.

Смотрите план выполнения.

Для фильтрации WHERE IN статический список, скорее всего, либо хэшируется, либо просто сортируется. В обоих случаях дубликаты при этом должны удаляться.

Answer 3

[Vitsliputsli]

Подскажите нормально ли это или нет?

Смотря какие нормы применяете.
Будет ли СУБД повторно сравнить с каждым дублем? Нет, не будет.
Где лучше отсеивать дубли? С учетом, что СУБД чаще всего узкое место, тем более если приложение работает в нескольких инстансах, то лучше конечно на стороне приложения.