А в каких кейсах критично дампить последние значение сиквенции?

На ум приходит только если сиквенции юзать вне логики БД

индекса или сиквенса?

Сиквенции

всем добрый вечер! подскажите, пожалуйста, а почему может быть что sql запрос с результатом всего на 2 млн строк (4 столбца, без расчетных функций и групбаев с дистинктами - всё из одной базы и даже таблицы, без джоинов) может выполняться 30 минут? данные на серве (postgres 12.3 на линуксе, дергаю с локального dbeaver'ом на винде), ресурсы не загружены даже вполовину. дополню, что 2 из 4 столбцов берут данные из xml'ей (unnest, cast, xpath...array...as text) с того же серва, где сам postgres. или в такой ситуации 30 минут это нормально?

если использовать автоинкремент
в новой базе при инсерте будут дублироваться ключи

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

да, спасибо!

Понял. Спасибо.

что-то подобное реально сделать? То есть я создаю временную таблицу и хочу обновить существующую, которую создал на ее основе. Но выдает ошибку в drs(это алиас для временной таблицы)

а кто-то может сейчас по скайпу помочь с проблемой в sql ?

Можно код текстом? Перепечатывать неудобно, да и кусок справа за пределами скрина.

Ну или см. например https://kb.objectrocket.com/postgresql/how-to-use-the-postgres-to-update-from-another-table-1158

Я нуб, но я б просто таблицу временную влепил и по ней апдейтил бы, как по ссылке описано. Ну или через CTE вместо времянки, вроде тоже должно сработать

у меня сейчас немного поменялась ситуация

UPDATE deposit_requests SET link_uuid = drs.link_uuid, state = 'in_chunk' FROM
(SELECT deposit_requests.address, SUM(deposit_requests.value) as sum, uuid_generate_v4() AS link_uuid, 'in_chunk'
FROM deposit_requests
WHERE deposit_requests.state = 'open'
GROUP BY deposit_requests.address, deposit_requests.link_uuid) drs
WHERE deposit_requests.address = drs.address AND deposit_requests.state = 'open'

INSERT INTO requests_chunk (uuid, address, sum) select link_uuid,address, sum from drs;

Со 2 по 4 строку я создаю временную таблицу, затем на 1 (условие на 6) делаю апдейт существующей с помощью данных из этой, а затем мне нужно вписать значения из этой таблицы в еще одну

мне предложили вариант с тем, что бы разбить это на 2 запроса, но в таком случае конструкцию со 2 по 4 строки мне тоже придется вызывать дважды. И проблема в том, что uuid_genetare_v4() отработает снова что приведет к тому, что будут соверешенно разные айдишники

Если вкратце, то в таблицу deposit_requests приходят данные, затем мне нужно объеденить реквесты для одного адреса в один. Знаю, что можно сделать через on conflict но мне это не подходит. По ситуации решил делать временную таблицу где буду суммировать и формировать uuid, и такое же поле буду держать во второй базе, что бы была связь между реквестами из первой и объединенными реквестами из второй

Я просто не знаю, может есть варианты по проще и оптимальнее это сделать

предлагаю в дискорде или скайпе вместе разобраться))
голос + показ экрана тудым-сюдым

ну было бы здорово если есть время

сейчас можешь?