Соблюдается ли очередь данных при нескольких bulk-insert операциях?

Question

[lightseeker]

Есть 2 команды, которые выполняются одновременно

INSERT INTO test_table (name) VALUES ('A'), ('B'), ('C), ('D'), ('E')

INSERT INTO test_table (name) VALUES ('F'), ('G'), ('H), ('I'), ('J')

Могут ли их primary key id смешиватЬся?
То есть, если запросить дату с ORDER BY id, и получить

1, A // из первого скрипта
2. F // из второго скрипта
3 B // из первого скрипта
4 G // из второго скрипта

Или всегда это будет вставлено поочередно? Ну, скажем, - сначала целиком первый или второй, смотря кто раньше пришёл ?

Answer 1

[Василий Банников]

Порядок данных при выборке никогда не гарантируется.
Порядок вставки тоже, при выполнении конкурирующих запросов.
Гарантируется только то, что у двух разных записей будет разный PK

Comments

[Алексей Черемисин]

Хотелось бы дополнить. В некоторых базах данных еще и зависит от типа блокировки - таблица или запись. Но PK гарантированно будет разный. А по хорошему - автоинкремент зло лютое.

[Мирон]

Уточнение, не по существу вопроса

Порядок данных при выборке никогда не гарантируется.

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

[mayton2019]

Хочется понять, какую выгоду ищет автор. Какие-бы решения или хитрости ему не посоветовали для PG, это совсем не будет работать в других БД (Oracle, Mysql).

Реляционная алгебра определяет строки как множество. Это - не массив. Более того, даже если вы пинками ухитрились создать видимость порядка, любая операция вакуума или прочая усушка и утруска сегмента данных - разрушит это.

[Василий Банников]

Мирон, может и сохраняется, но без order by СУБД имеет полное право выдавать их в произвольном порядке.

[mayton2019]

Василий Банников, есть некие побочные эффекты от вендоров. Например Oracle поддерживает так называемую ORGANIZATION INDEX таблицу. Это по сути гибрид таблицы и индекса. И он поддерживает физический ордеринг в соотвествии с ключом или группой ключей.

И если вставлять так в первой сессии так.

INSERT INTO test_table (session_id, name) VALUES ('2022/06/09-SID001','A');

И в другой сессии загрузки так session_id='2022/06/09-SID002' то строки будут группироваться вокруг сессионного ключа. И при select мы будем видеть иллюзию ордеринга по сессии.

Но другое дело что в Oracle IOT-таблицы не расчитаны на bulk и имеют другие лимиты на длину данных.

Разумеется это в PG не работает.

И конечно реляционная алгебра вообще понятия не имеет об IOT таблицах.

[Мирон]

Василий Банников,
А Вы попробуйте, вместо того, чтобы возражать.
Всегда есть что то новое :)
Всего доброго

[Василий Банников]

Мирон, :)

Answer 2

[Melkij]

Могут ли их primary key id смешиватЬся?
То есть, если запросить дату с ORDER BY id, и получить

Да.

За генерацию значений отвечают sequence (неважно каким именно способом объявлена таблица - default nextval явно созданного сиквенса, serial или generated identity - это всё будет сиквенс).
Сиквенс гарантирует только уникальность своих значений. Никаких гарантий порядка записи в таблицу он не даёт.

Два параллельных insert в postgresql так же друг друга никак не блокируют и исполняются конкурентно. Кто и в каком порядке надёргал nextval сиквенса потребное для своих данных количество раз - такие значения они и запишут.