Исчерпывающе для начала

Спасибо.

Есть у меня view

CREATE OR REPLACE VIEW public.contacts_count
AS SELECT contacts.user_id,
    count(contacts.user_id) AS count
   FROM contacts
  WHERE contacts.contact_origin::text = 'Authentic'::text
  GROUP BY contacts.user_id;

И на этот view я шлю запрос select (*) from contacts_count, вот этот запрос выполняется очень долго
Вот експлейн https://explain.depesz.com/s/InfQ - это на локале
PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit на локале
На проде PostgreSQL 11.6 (Ubuntu 11.6-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0, 64-bit

CREATE OR REPLACE VIEW public.contacts_count
AS SELECT contacts.user_id,
    count(contacts.user_id) AS count
   FROM contacts
  WHERE contacts.contact_origin::text = 'Authentic'::text
  GROUP BY contacts.user_id;

\d contacts тоже покажите.

Так, а это что?

Метакоманда psql для вывода описания объекта (таблицы, на которой основан view, в данном случае):

\d contacts

Покажите результат.

\d contacts

Это в консоле прописывать? Или вот этот результат нужен?

CREATE TABLE public.contacts (
  id bigserial NOT NULL,
  user_id int8 NOT NULL,
  phone_number varchar NULL,
  country_code varchar NULL,
  contact_name varchar NULL,
  email varchar NULL,
  company varchar NULL,
  job_title varchar NULL,
  account_name varchar NULL,
  contact_group int4 NULL,
  created_at timestamp NULL,
  updated_times int8 NOT NULL DEFAULT 0,
  contact_origin varchar NULL,
  CONSTRAINT contacts_pk PRIMARY KEY (id),
  CONSTRAINT contacts_un UNIQUE (user_id, phone_number, country_code)
);
CREATE UNIQUE INDEX contacts_id_uindex ON public.contacts USING btree (id);
CREATE INDEX contacts_phone_number_country_code_idx ON public.contacts USING btree (phone_number, country_code);

CREATE TABLE public.contacts (
  id bigserial NOT NULL,
  user_id int8 NOT NULL,
  phone_number varchar NULL,
  country_code varchar NULL,
  contact_name varchar NULL,
  email varchar NULL,
  company varchar NULL,
  job_title varchar NULL,
  account_name varchar NULL,
  contact_group int4 NULL,
  created_at timestamp NULL,
  updated_times int8 NOT NULL DEFAULT 0,
  contact_origin varchar NULL,
  CONSTRAINT contacts_pk PRIMARY KEY (id),
  CONSTRAINT contacts_un UNIQUE (user_id, phone_number, country_code)
);
CREATE UNIQUE INDEX contacts_id_uindex ON public.contacts USING btree (id);
CREATE INDEX contacts_phone_number_country_code_idx ON public.contacts USING btree (phone_number, country_code);

Это "прописывать" в psql. Это единственный "официальный" клиент, а откуда Вы берёте вот это вот, я не знаю (бывает, что другие GUI / клиенты выдают DDL не полностью или перевирают его). ;)

А так, по плану — таблица в основном считывается с диска (или, по крайней мере, из кеша FS — PostgreSQL не различает, откуда), и это 6 GB, и почти у всех записей contact_origin = 'Authentic' (кстати, использовали бы Вы text вместо varchar, по-хорошему).
Поэтому тут всё зависит от производительности диска или наличия достаточного кол-ва RAM (и настроек сервера PostgreSQL и OS, соответственно).

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

CREATE INDEX ON contacts(contact_origin, user_id);
CREATE INDEX ON contacts(user_id) WHERE contact_origin = 'Authentic';

И да, зачем Вы используете COUNT(contacts.user_id), когда user_id int8 NOT NULL? Достаточно COUNT(*).

Поддерживает.

CREATE INDEX ON contacts(contact_origin, user_id);
CREATE INDEX ON contacts(user_id) WHERE contact_origin = 'Authentic';

А почему planning time так сильно отличается от execution time? Потому что у меня постгрес развернут в докере, это проблема на локале такого долгого запроса?

Потому что и должно? ;) Это совершенно разные вещи, если что.

Запустил на проде, только where там отсутствует, так там всё очень быстро выполнилось

Planning Time: 1.155 ms
Execution Time: 5943.528 ms

Да, понимаю.

Planning Time: 1.155 ms
Execution Time: 5943.528 ms

А Вы план там посмотрите — или настройки другие, или таблица уже "сидит" в RAM... и см. выше.

Всем привет, такая задача, есть система ремонта техники, нужно генерировать много клиентов и технику, один клиент может принести много техники, подскажите пожалуйста, как лучше всего сделать генерацию техники (например клиентов 10к, техники 15к), чтобы у каждого клиента точно была 1 единица техники, а остаток техники распределить случайно между всеми клиентами?

тебе тестовые данные что ли

Похоже на то, что на PROD либо диск лучше, либо большая часть таблицы — в кеше FS.
И вот ещё что:

Buffers: shared hit=11185 read=665237 dirtied=2
-- PROD:
Buffers: shared hit=222 read=346797 dirtied=243 written=27

Получается, что на PROD читается меньше данных — Вы массового UPDATE (всей таблицы или около того) на этом тестовом сервере не выполняли, случайно?

Buffers: shared hit=11185 read=665237 dirtied=2
-- PROD:
Buffers: shared hit=222 read=346797 dirtied=243 written=27

Да, не выполнял