Гость
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Критически долго выполняется запрос / 11 сообщений из 11, страница 1 из 1
31.08.2017, 15:31
    #39513510
pixxxel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
Есть таблица со множеством полей типа:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
CREATE TABLE big_data
(
  id serial NOT NULL,
  ...
  is_active boolean NOT NULL,
  source_id integer NOT NULL,
  CONSTRAINT big_data_pkey PRIMARY KEY (id)
);



Есть общий индекс btree на is_active и source_id.

Запрос во вновь созданной таблице на 7 млн. сгенерированных записей

Код: plsql
1.
SELECT id FROM big_data WHERE is_active IS TRUE AND source_id=2 ORDER BY id DESC LIMIT 1;



отрабатывает вполне себе шустро, а вот с боевого накатываю 7 млн.записей -- выполняется более получаса и не дает результатов. При этом в логе этот запрос показывается и EXPLAIN-ы (без выполнения) на обоих наборах данных почти одинаковые.

В чем может быть причина? Или как можно диагностировать проблему?
...
Рейтинг: 0 / 0
31.08.2017, 15:38
    #39513517
Alex__kK
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
pixxxel,

Так и покажи explain (analyze, buffers) проблемного запроса
...
Рейтинг: 0 / 0
31.08.2017, 15:56
    #39513529
Lonepsycho
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
pixxxel,

а новые записи вы "накатываете" через COPY?
...
Рейтинг: 0 / 0
31.08.2017, 16:33
    #39513552
Alexius
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
pixxxel,

индекс видимо надо подходящий. скорей всего что-то вроде (source_id, id) или (source_id, id) where is_active. надо смотреть что за данные там.
...
Рейтинг: 0 / 0
02.09.2017, 11:31
    #39514399
pixxxel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
Lonepsycho,

pg_dump одна таблица, потом psql < file
...
Рейтинг: 0 / 0
02.09.2017, 11:34
    #39514400
pixxxel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
Alex__kK,

Вроде немного проясняется. Всё дело в том, что есть 2 таблицы. Одна с рабочими данными, а другая тестовая для опытов.
Рабочая:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CREATE TABLE public."big_data"
(
  "id" INTEGER NOT NULL DEFAULT NEXTVAL((pg_get_serial_sequence('"public"."big_data"'::text, 'id'::text))::regclass),
  ...
  source_id SMALLINT,
  is_active BOOLEAN DEFAULT TRUE,
  CONSTRAINT "pbig_data" PRIMARY KEY ("id")
)
WITH (
  OIDS=FALSE
);
CREATE INDEX "ibig_data-source_id__is_active"
  ON public."big_data"
  USING btree
  (source_id, is_active)
  WHERE source_id IS NOT NULL AND is_active;


и та на которой я всё тестирую, заполненная примерно таким же количеством данных:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CREATE TABLE public.big_data
(
  id INTEGER NOT NULL DEFAULT NEXTVAL('big_data_id_seq'::regclass),
  text_data text,
  is_active BOOLEAN DEFAULT TRUE,
  source_id SMALLINT,
  CONSTRAINT big_data_pkey PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
CREATE INDEX big_data_source_id_index
  ON public.big_data
  USING btree
  (source_id, is_active)
  WHERE source_id IS NOT NULL AND is_active;


Так вот. Один и тот же запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
EXPLAIN SELECT
    "id"
FROM
    "big_data"
WHERE
    source_id = 6
    AND is_active
ORDER BY "id" DESC
LIMIT 1


и
Код: sql
1.
EXPLAIN SELECT id FROM big_data WHERE is_active AND source_id=2 ORDER BY id DESC LIMIT 1;


даёт разные результаты - в одном индекс используется, в другом - нет:
Код: sql
1.
2.
3.
"Limit  (cost=0.43..220.64 rows=1 width=4)"
"  ->  Index Scan Backward using "pbig_data" on "big_data"  (cost=0.43..10254585.72 rows=46567 width=4)"
"        Filter: (is_active AND (source_id = 6))"


Код: sql
1.
2.
3.
4.
5.
6.
7.
"Limit  (cost=11.26..11.26 rows=1 width=4)"
"  ->  Sort  (cost=11.26..11.26 rows=3 width=4)"
"        Sort Key: id DESC"
"        ->  Bitmap Heap Scan on big_data  (cost=4.13..11.24 rows=3 width=4)"
"              Recheck Cond: ((source_id = 2) AND is_active)"
"              ->  Bitmap Index Scan on big_data_source_id_index  (cost=0.00..4.13 rows=3 width=0)"
"                    Index Cond: (source_id = 2)"
...
Рейтинг: 0 / 0
02.09.2017, 12:15
    #39514417
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
pixxxel,

индексы используются в обоих запросах. Но первый решил, что дешевле читать сортировку по pk, попутно накладывая фильтр в расчёте, что limit 1 быстро найдётся по краю индекса, а второй - что дешевле фильтр получить по индексу, а сортировать в памяти.
И фильтр и сортировку по индексу можно получить с индексом
Код: sql
1.
2.
(source_id, id)
  WHERE source_id IS NOT NULL AND is_active;



И просто для интереса, с какой целью вы для частичного индекса с условием is_active включаете в индекс этот самый is_active? Чтобы просто увеличить размер индекса хранением бесполезных данных?
...
Рейтинг: 0 / 0
02.09.2017, 12:26
    #39514420
pixxxel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
Melkij,

спасибо огромное за подробное разъяснение!

"...с какой целью вы..." - очевидно потому, что еще очень плохо разбираюсь с тем как работают индексы )))

Еще раз спасибо!
...
Рейтинг: 0 / 0
02.09.2017, 15:56
    #39514463
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
Melkij
И просто для интереса, с какой целью вы для частичного индекса с условием is_active включаете в индекс этот самый is_active? Чтобы просто увеличить размер индекса хранением бесполезных данных?
IOS , если в запросе к нему формально обращаться.
иначе г-н пж планирует IS -- т.е. будет запись фетчить.
такие дела.
...
Рейтинг: 0 / 0
02.09.2017, 16:38
    #39514470
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
qwwqMelkijИ просто для интереса, с какой целью вы для частичного индекса с условием is_active включаете в индекс этот самый is_active? Чтобы просто увеличить размер индекса хранением бесполезных данных?
IOS , если в запросе к нему формально обращаться.
иначе г-н пж планирует IS -- т.е. будет запись фетчить.
такие дела.
Ага, при том что сам is_active не выбирается. А если бы выбирался - select true as is_active даст тот же самый результат запроса и желанный IOS.
...
Рейтинг: 0 / 0
02.09.2017, 17:09
    #39514480
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критически долго выполняется запрос
Melkijqwwqпропущено...

IOS , если в запросе к нему формально обращаться.
иначе г-н пж планирует IS -- т.е. будет запись фетчить.
такие дела.
Ага, при том что сам is_active не выбирается. А если бы выбирался - select true as is_active даст тот же самый результат запроса и желанный IOS.
и что теперь
, они типа рыбу заворачивали, а я в положение входи. запросы переписывай. ага.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
CREATE UNIQUE INDEX 
  ON public.corellations_2_d3_all_id
  USING btree
  (id, lexeme_1 COLLATE pg_catalog."default")
  WHERE lexeme_1 IS NULL AND  lexeme_2 IS NULL;


explain
SELECT count(lexeme_2) FROM public.corellations_2_d3_all_id 
WHERE lexeme_1 IS NULL AND lexeme_2 IS NULL;

'Aggregate  (cost=5.90..5.91 rows=1 width=8)'
'  ->  Index Scan using corellations_2_d3_all_id_id_lexeme_1_idx on corellations_2_d3_all_id  (cost=0.12..5.89 rows=1 width=11)'

explain
SELECT count(lexeme_1) FROM public.corellations_2_d3_all_id 
WHERE lexeme_1 IS NULL AND lexeme_2 IS NULL;

'Aggregate  (cost=5.90..5.91 rows=1 width=8)'
'  ->  Index Only Scan using corellations_2_d3_all_id_id_lexeme_1_idx on corellations_2_d3_all_id  (cost=0.12..5.89 rows=1 width=11)'



пусть планер пашет -- он железный.

лучше сразу например расстрелять виновника необходимости 2--х практицки одинаковых индексов на текстовые поля . вот уж где перерасход, так перерасход.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Критически долго выполняется запрос / 11 сообщений из 11, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]