Кроме него

Просто я смотрю какой он красивый join делает)

На темп табличку тоже накинь

Хорошо.

На фильтр через IN он у тебя 16 сек тратит, он ломается на сортировке и джойне, в теории btree на оба значения в обоих таблицах должно разогнать запрос в разы

В чем его «красота»?) мне эта задача пришла как есть вчера. Я честно не силён, но больше некому увы.

На время его исполнения если посмотреть) становится грустно:(

Спасибо, займусь минут через 30.

Недостаточно информации, совсем. :(
И зря у Вас там "fsync = off". Для unlogged table это ничего не даёт (даже при CHECKPOINT, насколько я помню), а вот кластер Вы потеряете, если что.
Вы бы показали, как / куда заливаете (может, проблема именно в самом этом процессе).

Это да. Это ещё скоромно, до этого сатанисты пытались извлекать по 4 млн строк

заливаю из питона через psycopg2, демон вычитывает txt файл построчно (150 млн строк читаются за ~10 минут если вхолостую),
по поводу потери данных в курсе, но там абсолютно пустая база в этот момент, поэтому не страшно такое включать 🙂 да и данные не так важны, можно и перезапустить если что, просто хочется быстрее их вставлять в базу.

Вставляю в таблицу без индексов вот такую:
CREATE UNLOGGED TABLE domain (
   id SERIAL NOT NULL,
   tld_id INTEGER NOT NULL,
   letter VARCHAR(1) NOT NULL,
   name_servers INTEGER[] NOT NULL,
   created_at DATE DEFAULT NOW() NOT NULL,
   updated_at DATE,
   deleted_at DATE,
   domain VARCHAR(70) NOT NULL,
   PRIMARY KEY (id, letter)
) PARTITION BY LIST (letter);

CREATE UNLOGGED TABLE domain_letter_0 PARTITION OF domain FOR VALUES IN ('0');
...
CREATE UNLOGGED TABLE domain_letter_9 PARTITION OF domain FOR VALUES IN ('9');
CREATE UNLOGGED TABLE domain_letter_a PARTITION OF domain FOR VALUES IN ('a');
CREATE UNLOGGED TABLE domain_letter_b PARTITION OF domain FOR VALUES IN ('b');
...
CREATE UNLOGGED TABLE domain_letter_z PARTITION OF domain FOR VALUES IN ('z');

Всё это происходит на VPS от хетцнера, 4ГБ рам, 3 ядра, SSD, но по ресурсам я бы не сказал что упирается в потолок 🙁

заливаю пачку на 10к строк если что вот так:

conn = self.db.raw_connection()
with conn.cursor() as cur:
   # https://www.psycopg.org/docs/cursor.html#cursor.copy_from
   cur.copy_from(
       self._bulk_domains,
       'domain',
       sep='\t',
       columns=('tld_id', 'letter', 'name_servers', 'domain'),
   )
conn.commit()

Выглядит все более чем, странно

а что именно странно? я совсем не DBA )

Я тоже)

Привет. Не могу найти ответ на вопрос. Пусть есть бд. Есть несколько бекендов, которые хотят получить из одной таблицы данные. В таблице дофига много данных. Один запрос выполняется долго. Чтобы обеспечить множественное обращение нужно копировать записи и обращаться к копиям? ТО есть нельзя никак единовременно обратиться к одной таблице ?

> да и данные не так важны, можно и перезапустить если что

Вам не перезапустить придётся, а реинциализировать кластер баз данных (initdb). Если там есть другие БД, их Вы тоже потеряете. И на все эти минусы Вы "подписались", не получая никаких плюсов, насколько я вижу. ;)

> Вставляю в таблицу без индексов вот такую:

Индекс у Вас тут есть, кстати — вот же: "PRIMARY KEY (id, letter)". Если это однократная / массовая загрузка, создать его потом может быть намного лучше.

> created_at DATE DEFAULT NOW() NOT NULL

Кстати, правильнее current_date, наверное. Ну и вообще, см. https://wiki.postgresql.org/wiki/Don%27t_Do_This про varchar(n) и работу с датой/временем.

> PARTITION BY LIST (letter);

А зачем она партиционирована, вообще (150 млн. кажется как-то мало для того, чтобы об этом даже думать)?

> Всё это происходит на VPS от хетцнера, 4ГБ рам, 3 ядра, SSD,

А какая это версия PostgreSQL? И сколько это данных получается в гигабайтах (лень считать, да и Вам виднее ;) )?

Попробуй убрать primary key и not null везде без partition

А, понял

Привет, можно