эти все запросы взяты по подобию отсюда (3.1. Алгоритм полной синхронизации -> DELETE, UPDATE, INSERT): https://habr.com/ru/company/tensor/blog/492464/ - там КЛАДР таким образом обновляют, я их не сам придумал 🙈

> Вы же данные о name_servers так фактически удаляете, или важно наличие "пустой" записи почему-то?
я физически строки не хочу удалять, по факту можно отказаться от того чтоб менять поле name_servers, когда я проставляю поле deleted_at, но мне почему-то показалось что так pg подчистит за собой в этом месте, чтоб каждый день уделенные и ненужные домены не занимали лишнее место на ns сервера )

> И зачем там этот странный синтаксис для anti join, да и вообще лишний self join, на первый взгляд?
я не смог его по-другому переписать, чтоб он работал также 😄

> Я бы его сначала переписа
А что тут можно изменить, чтоб запрос не поломался? Там ведь вся соль в том, что у нас есть таблица t1 с 150 млн строк со вчерашнего дня (да и вообще - с прошлых дней), я в новую t2 заливаю новые данные (где может быть от силы обновится всего 150 тысяч строк из 150 млн), потом через эти апдейты с антиджоинами / инсеры делаю следующее:

1. вначале помечаю в t1 те строки, что отсутствуют в t2 (удаляю фактически, но без физического удаления)
2. обновляю в t1 измененные в t2 строки
3. те что были удалены в t1 ранее, но снова появились в t2 - тоже меняю, чтоб сменить у них crated_at
4. вставляю все строки из t2, которые отсутствуют в t1

вот такая логика там, чтоб таблица t1 содеражала всё что было в предыдущие дни, но новые/обновленные данные из t2 там тоже присутствовали, то есть состояние базы всегда должно быть актуальным 🙂

UPD: Полный пример для воспроизведения выложил тут: https://pastebin.com/2bpcmqAT

т.е. строки не фиксированного размера в файле?

> там КЛАДР таким образом обновляют, я их не сам придумал 🙈

Лучше б Вы их сами придумали, судя по их виду (статью не смотрел). ;)

> я физически строки не хочу удалять,

Мне вот и непонятно, почему, если Вы информацию в них, фактически, уничтожаете.
Я бы понял, если бы name_servers не менялось (можно было бы "исторические" запросы делать, допустим), а так-то зачем?

> я не смог его по-другому переписать, чтоб он работал также 😄

А Вы с [NOT] EXISTS попробуйте.

> вот такая логика там

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

> там КЛАДР таким образом обновляют, я их не сам придумал 🙈

Лучше б Вы их сами придумали, судя по их виду (статью не смотрел). ;)

> я физически строки не хочу удалять,

Мне вот и непонятно, почему, если Вы информацию в них, фактически, уничтожаете.
Я бы понял, если бы name_servers не менялось (можно было бы "исторические" запросы делать, допустим), а так-то зачем?

> я не смог его по-другому переписать, чтоб он работал также 😄

А Вы с [NOT] EXISTS попробуйте.

> вот такая логика там

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

ой, кладр. страшные слова

от ФИАС'а легче?

я бы рад такое и сам придумать, но я не осилил)) поэтому и не могу осилить их изменение до человеческого вида 🙂

> Я бы понял, если бы name_servers не менялось (можно было бы "исторические" запросы делать, допустим), а так-то зачем?
удаление физическое не делаю только потому, что очень много "дырок" появится тогда, да и вроде delete будет "тяжелее" чем update в моем случае, но может ошибаюсь..
в целом, можно name_servers действительно не менять, проставлять только deleted_at

> А Вы с [NOT] EXISTS попробуйте.
а можете, пожалуйста, показать пример как тут это сджойнить и использовать not exists без вложенного запроса (он ведь вроде медленнее будет для меня)?

> В общем, нашли бы Вы образец для подражания получше где-нибудь (лично мне это даже править не хочется, хочется сразу выкинуть). 😉
если знаете где-то пример организации обновления данных в 1й таблице на основе данных из таблицы 2 - буду благодарен! тот пример с хабра от Кирилла Боровикова вообще чудом нашел

> удаление физическое не делаю только потому, что очень много "дырок" появится тогда,

Хмм... ну и что? Чем они мешают?

> да и вроде delete будет "тяжелее" чем update в моем случае, но может ошибаюсь..

DELETE в PostgreSQL просто помечает запись, как удалённую. А UPDATE записывает новую версию записи, целиком.
Мне как-то трудно представить, чтобы первое в какой-то ситуации было "тяжелее" второго.

> без вложенного запроса (он ведь вроде медленнее будет для меня)?

Почему он будет медленнее? В том запросе тоже написан (или, по крайней мере, есть попытка его написать ;) ) anti join (который в SQL выражается с помощью NOT EXISTS), только криво.
Мне кажется, что у Вас есть какое-то очень превратное представление о том, как работают оптимизаторы SQL запросов в СУБД. Планы в принципе мало связаны с тем, как запрос написан; мифы вроде "вложенные запросы медленнее" и т.п. — это просто чушь. ;(

> если знаете где-то пример организации обновления данных в 1й таблице на основе данных из таблицы 2

Сходу не скажу. Но задача же нередкая (я помню, что-то такое даже в этом чате обсуждали), странно, что не удаётся найти...

Странно, что кладр в 2020 году все ещё есть

Привет. Пластиком, есть ли возможность делать bulk insert с xls файлов?