Столбец IDENTITY
равен , и не гарантируется получение последовательных значений . Это гарантирует назначение уникальных и монотонных значений.
Вы можете решить вашу проблему с некоторыми sql после загрузки данных:
CREATE TABLE my_table_with_consecutive_ids AS
SELECT
row_number() over (order by bucketingid) as consecutive_bucketingid,
*
FROM my_table
Некоторые объяснения, почему возникает проблема:
Поскольку COPY
выполняет распределенную загрузку ваших данных, и каждый файл загружается срезом узла, загрузка только одного файла будет обрабатываться одним срезом. Чтобы иметь возможность гарантировать уникальные значения при одновременной загрузке данных различными срезами, каждый из них использует пространство идентификаторов, исключающее себя (с 2 срезами, один использует нечетные, а другой четные числа).
Теоретически, у вас могут быть последовательные идентификаторы после загрузки данных, если вы разбили файл на две части ( или любое другое число срезов, которое имеет ваш кластер ) и использовали оба среза для загрузки (вам понадобится использовать MANIFEST
файл), но это очень непрактично, и вы также делаете предположения о размере кластера.
То же объяснение из CREATE TABLE
руководство :
ИДЕНТИЧНОСТЬ (семя, шаг)
...
С помощью операции COPY данные загружаются параллельно и распределяются по частям узла. Чтобы убедиться, что значения идентификаторов являются уникальными, Amazon Redshift пропускает несколько значений при создании значений идентификаторов. В результате значения идентификаторов являются уникальными и последовательными, но не последовательными, и порядок может не соответствовать порядку в исходных файлах.