Запрос выполняется очень медленно
https://t.me/pgsql/288632
А нужен ли индекс в данный момент? Чтобы делать селект по user_id? Но он мне тут не нужен, я же вытаскиваю всё view
Но этого-то Вы тоже не написали. В общем, если действительно нужна помощь по производительности, лучше показывать всё это сразу.
Есть у меня 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, вот этот запрос выполняется очень долго
Ещё раз, покажите всё запрошенное, иначе Вы просто впустую тратите время, понимаете?
Имеете в виду, что я должен показать еще explain (analyze, buffers)?
Всё перечисленное в https://t.me/pgsql/288632
Ага, благодар. Дождусь результатов explain
Есть у меня 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
\d contacts тоже покажите.
Так, а это что?
Метакоманда psql для вывода описания объекта (таблицы, на которой основан view, в данном случае): \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);
Это "прописывать" в 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(*).
А почему planning time так сильно отличается от execution time? Потому что у меня постгрес развернут в докере, это проблема на локале такого долгого запроса?
Потому что и должно? ;) Это совершенно разные вещи, если что.
Обсуждают сегодня