Загрузка с уник. ключом в неск. сессий

В таблице имеется уникальный ключ.
В эту же таблицу льются данные из нескольких сессий (сотни тыс. записей)
Понятно, что пока одна сессия не закомитилась, другие ждут.
Вопрос, можно ли как-то оптимизировать, чтобы уйти от ожиданий? (не убирая уник. ключ).

Т.к. среди заливаемых данных довольно много таких, которые будут отпадать как раз по констрейнту уникальности, понятно, что можно тупо прежде проверять селектом - если уже есть такая запись, то инсерт не делаем, это должно бы ощутимо уменьшить кол-во ожиданий.

В общем пока вижу только: предв. селект + commit после каждого инсерта.

Еще вариант сначала лить все в промежуточную таблицу (без ограничений уникальности), а потом запустить обработчик, который уже перетащит все в постоянную рабочую таблицу.

Но может есть другой чудесный и простой вариант? )

Может кого-то натолкнет на мысль: таблицу можно разбить на патиции так, что каждая сессия будет лить данные в свою патицию )
Меня тоже это куда-то толкает )

JDS
можно тупо прежде проверять селектом - если уже есть такая запись, то инсерт не делаем,

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

JDS,

Нефига использовать натуральные ключи. Сиквенс и несколько потоков. Либо в стейдж область заливать, проверять и потом переливать. Это разовая задача?

JDS,

Если дублей немного ожидается, то можно отключить констрейнт и потом удалить дубли.

JDS
Вопрос, можно ли как-то оптимизировать, чтобы уйти от ожиданий?

Пускай непосредственной вставкой занимается одна сессия.

andreymx
если предыдущий чел не закоммитился, хрен ты ту вставленную запись увидишь

Это да. Но подразумевается, что в 99% разные сесси льют все-такие разные данные.

Пыщ-пыщ мобайл
Нефига использовать натуральные ключи. Сиквенс и несколько потоков. Либо в стейдж область заливать, проверять и потом переливать. Это разовая задача? Если дублей немного ожидается, то можно отключить констрейнт и потом удалить дубли.

иквенс это да, но требование ун,, , икальности никто не отменяет)
Заливать сначала в "буферную" таблицу, потом переливать, пока кажется усложнением, чего не.хотелось бы. Дублей ожидается много, поэтому хотелось бы сразу из не грузить, чем потом чистить.
публиш субскрибов, вариант. Использовать некую очередь запросов (вроде в оракл что-тт было такое? И одной сессией ее разгребать. Вполне подошло бы имхо. Ну и еще проверю насчет патиционирования все-таки (локальный уник. индекс не?))

JDS
В таблице имеется уникальный ключ. В эту же таблицу льются данные из нескольких сессий (сотни тыс. записей)

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

JDS
Вопрос, можно ли как-то оптимизировать, чтобы уйти от ожиданий? (не убирая уник. ключ)

В данном случае оптимизация напрашивается с постановки задачи. Потому что сам по себе факт того, что несколько крупных источников льют данные, из которых выбираются записи-везунчики методом "кто первый встал" крайне не похож на правильную реализацию разумной потребности.

softwarer, есть ряд не зависящих от меня обст-в, в частности, что льется все по 10 раз, "архитектор" тут ни при чем, но плодить в базе кучи дублей или потом вычищать их... хотелось бы сразу класть в базу.только то что нужно ) в целом возможные варианты понял, остается выбрать, мож и через буферную табличку в итоге.

JDS
softwarer, есть ряд не зависящих от меня обст-в

Значит, пинайте того, от кого они зависят. И почитайте хотя бы в районе слов проект, о котором рассказывает кандидат.