Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему не используется индекс??? / 6 сообщений из 6, страница 1 из 1
20.09.2007, 18:41
    #34815766
Winnipuh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему не используется индекс???
есть таблица
CREATE TABLE "public"."xprop2" (
"id_seq" SERIAL,
"node_id" "public"."uuid" NOT NULL,
"xpath" VARCHAR,
"xstring" VARCHAR,
"parent_id" "public"."uuid",
"xaccess" VARCHAR,
"xstring_vector" "public"."tsvector",
"xpath_vector" "public"."tsvector",
"node_type" INTEGER,
"node_subtype" INTEGER,
"xaccess_vector" "public"."tsvector",
"creation_date" TIMESTAMP(0) WITHOUT TIME ZONE,
"modification_date" TIMESTAMP(0) WITHOUT TIME ZONE
) WITHOUT OIDS;

DROP INDEX xprop2_created_idx;
DROP INDEX xprop2_04_created_idx;
DROP INDEX xprop2_05_created_idx;
DROP INDEX xprop2_06_created_idx;
DROP INDEX xprop2_07_created_idx;

CREATE INDEX xprop2_created_idx ON xprop2 (creation_date);
CREATE INDEX "xaccess2_idx" ON "public"."xprop2" USING gist ("xaccess_vector");
CREATE INDEX "xpath2_idx" ON "public"."xprop2" USING gist ("xpath_vector");
CREATE INDEX "xstring2_idx" ON "public"."xprop2" USING gist ("xstring_vector");


это нормальный план?
m135=# explain analyze
m135-# select * from xprop2 where
m135-# creation_date > ('2007-01-01'::date + '1 month'::interval) limit 100;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..6.88 rows=100 width=354) (actual time=0.009..0.211 rows=100 loops=1)
-> Result (cost=0.00..162.93 rows=2369 width=354) (actual time=0.009..0.168 rows=100 loops=1)
-> Append (cost=0.00..162.93 rows=2369 width=354) (actual time=0.007..0.116 rows=100 loops=1)
-> Seq Scan on xprop2 (cost=0.00..13.50 rows=93 width=252) (actual time=0.001..0.001 rows=0 loops=1)
Filter: (creation_date > '2007-02-01 00:00:00'::timestamp without time zone)
-> Seq Scan on xprop2_07 xprop2 (cost=0.00..149.43 rows=2276 width=354) (actual time=0.006..0.071 rows=100 loops=1)
Filter: (creation_date > '2007-02-01 00:00:00'::timestamp without time zone)
Total runtime: 0.274 ms
(8 rows)
...
Рейтинг: 0 / 0
20.09.2007, 18:55
    #34815796
iz
iz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему не используется индекс???
Winnipuhесть таблица
CREATE TABLE "public"."xprop2" (
"id_seq" SERIAL,
"node_id" "public"."uuid" NOT NULL,
"xpath" VARCHAR,
"xstring" VARCHAR,
"parent_id" "public"."uuid",
"xaccess" VARCHAR,
"xstring_vector" "public"."tsvector",
"xpath_vector" "public"."tsvector",
"node_type" INTEGER,
"node_subtype" INTEGER,
"xaccess_vector" "public"."tsvector",
"creation_date" TIMESTAMP(0) WITHOUT TIME ZONE,
"modification_date" TIMESTAMP(0) WITHOUT TIME ZONE
) WITHOUT OIDS;

DROP INDEX xprop2_created_idx;
DROP INDEX xprop2_04_created_idx;
DROP INDEX xprop2_05_created_idx;
DROP INDEX xprop2_06_created_idx;
DROP INDEX xprop2_07_created_idx;

CREATE INDEX xprop2_created_idx ON xprop2 (creation_date);
CREATE INDEX "xaccess2_idx" ON "public"."xprop2" USING gist ("xaccess_vector");
CREATE INDEX "xpath2_idx" ON "public"."xprop2" USING gist ("xpath_vector");
CREATE INDEX "xstring2_idx" ON "public"."xprop2" USING gist ("xstring_vector");


это нормальный план?
m135=# explain analyze
m135-# select * from xprop2 where
m135-# creation_date > ('2007-01-01'::date + '1 month'::interval) limit 100;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..6.88 rows=100 width=354) (actual time=0.009..0.211 rows=100 loops=1)
-> Result (cost=0.00..162.93 rows=2369 width=354) (actual time=0.009..0.168 rows=100 loops=1)
-> Append (cost=0.00..162.93 rows=2369 width=354) (actual time=0.007..0.116 rows=100 loops=1)
-> Seq Scan on xprop2 (cost=0.00..13.50 rows=93 width=252) (actual time=0.001..0.001 rows=0 loops=1)
Filter: (creation_date > '2007-02-01 00:00:00'::timestamp without time zone)
-> Seq Scan on xprop2_07 xprop2 (cost=0.00..149.43 rows=2276 width=354) (actual time=0.006..0.071 rows=100 loops=1)
Filter: (creation_date > '2007-02-01 00:00:00'::timestamp without time zone)
Total runtime: 0.274 ms
(8 rows)

сделать analyze таблице после создания индекса по creation_date и повторить explain
...
Рейтинг: 0 / 0
20.09.2007, 19:33
    #34815886
Winnipuh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему не используется индекс???
сделал анализ всем таблицам: главной и выведенным
Такой план - лучше? ваше мнение...

m135=# explain analyze
m135-# select * from xprop2 where
m135-# creation_date > ('2007-01-01 00:00:00'::timestamp + '1 month'::interval)
m135-# and xstring_vector @@ to_tsquery('default','voice');
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Result (cost=0.00..66.54 rows=16 width=353) (actual time=3.195..15.876 rows=6394 loops=1)
-> Append (cost=0.00..66.54 rows=16 width=353) (actual time=3.194..12.421 rows=6394 loops=1)
-> Index Scan using xstring2_idx on xprop2 (cost=0.00..8.27 rows=1 width=252) (actual time=0.016..0.016 rows=0 loops=1)
Index Cond: (xstring_vector @@ '''voic'''::tsquery)
Filter: ((creation_date > '2007-02-01 00:00:00'::timestamp without time zone) AND (xstring_vector @@ '''voic'''::tsquery))
-> Bitmap Heap Scan on xprop2_07 xprop2 (cost=4.37..58.27 rows=15 width=353) (actual time=3.177..9.782 rows=6394 loops=1)
Filter: ((creation_date > '2007-02-01 00:00:00'::timestamp without time zone) AND (xstring_vector @@ '''voic'''::tsquery))
-> Bitmap Index Scan on xstring2_07_idx (cost=0.00..4.37 rows=15 width=0) (actual time=3.023..3.023 rows=6394 loops=1)
Index Cond: (xstring_vector @@ '''voic'''::tsquery)
Total runtime: 17.346 ms
(10 rows)
...
Рейтинг: 0 / 0
20.09.2007, 19:39
    #34815902
iz
iz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему не используется индекс???
Winnipuhсделал анализ всем таблицам: главной и выведенным
Такой план - лучше? ваше мнение...

m135=# explain analyze
m135-# select * from xprop2 where
m135-# creation_date > ('2007-01-01 00:00:00'::timestamp + '1 month'::interval)
m135-# and xstring_vector @@ to_tsquery('default','voice');
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Result (cost=0.00..66.54 rows=16 width=353) (actual time=3.195..15.876 rows=6394 loops=1)
-> Append (cost=0.00..66.54 rows=16 width=353) (actual time=3.194..12.421 rows=6394 loops=1)
-> Index Scan using xstring2_idx on xprop2 (cost=0.00..8.27 rows=1 width=252) (actual time=0.016..0.016 rows=0 loops=1)
Index Cond: (xstring_vector @@ '''voic'''::tsquery)
Filter: ((creation_date > '2007-02-01 00:00:00'::timestamp without time zone) AND (xstring_vector @@ '''voic'''::tsquery))
-> Bitmap Heap Scan on xprop2_07 xprop2 (cost=4.37..58.27 rows=15 width=353) (actual time=3.177..9.782 rows=6394 loops=1)
Filter: ((creation_date > '2007-02-01 00:00:00'::timestamp without time zone) AND (xstring_vector @@ '''voic'''::tsquery))
-> Bitmap Index Scan on xstring2_07_idx (cost=0.00..4.37 rows=15 width=0) (actual time=3.023..3.023 rows=6394 loops=1)
Index Cond: (xstring_vector @@ '''voic'''::tsquery)
Total runtime: 17.346 ms
(10 rows)

по крайней мере у вас планнер заметил индекс после analyze. дальше сами решайте, как эффективнее. начиная с нескольких тысяч записей в среднем индекс-скан начинает выигрывать у последовательного просмотра. но все также зависит от мощности выборки. если у вас в запросе вернется треть таблицы, лучше такой запрос делать seqscan-ом из-за очевидных особенностей физического доступа к жесткому диску (последовательное чтение гораздо быстрее рандомного).
...
Рейтинг: 0 / 0
20.09.2007, 19:44
    #34815908
Winnipuh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему не используется индекс???
iz Winnipuhсделал анализ всем таблицам: главной и выведенным
Такой план - лучше? ваше мнение...

m135=# explain analyze
m135-# select * from xprop2 where
m135-# creation_date > ('2007-01-01 00:00:00'::timestamp + '1 month'::interval)
m135-# and xstring_vector @@ to_tsquery('default','voice');
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Result (cost=0.00..66.54 rows=16 width=353) (actual time=3.195..15.876 rows=6394 loops=1)
-> Append (cost=0.00..66.54 rows=16 width=353) (actual time=3.194..12.421 rows=6394 loops=1)
-> Index Scan using xstring2_idx on xprop2 (cost=0.00..8.27 rows=1 width=252) (actual time=0.016..0.016 rows=0 loops=1)
Index Cond: (xstring_vector @@ '''voic'''::tsquery)
Filter: ((creation_date > '2007-02-01 00:00:00'::timestamp without time zone) AND (xstring_vector @@ '''voic'''::tsquery))
-> Bitmap Heap Scan on xprop2_07 xprop2 (cost=4.37..58.27 rows=15 width=353) (actual time=3.177..9.782 rows=6394 loops=1)
Filter: ((creation_date > '2007-02-01 00:00:00'::timestamp without time zone) AND (xstring_vector @@ '''voic'''::tsquery))
-> Bitmap Index Scan on xstring2_07_idx (cost=0.00..4.37 rows=15 width=0) (actual time=3.023..3.023 rows=6394 loops=1)
Index Cond: (xstring_vector @@ '''voic'''::tsquery)
Total runtime: 17.346 ms
(10 rows)

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

понял, спасибо!

по поводу количества возвращаемых: я явно буду резать limit 1000 или около того, но реально там будет больше. В таком случае важен будет не лимит, а реальное количество?
...
Рейтинг: 0 / 0
20.09.2007, 20:07
    #34815941
iz
iz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему не используется индекс???
Winnipuh
по поводу количества возвращаемых: я явно буду резать limit 1000 или около того, но реально там будет больше. В таком случае важен будет не лимит, а реальное количество?

нужно будет смотреть на explain analyze -- там явно будет написано кол-во рядов, с которыми работает executor до сортировки и лимита -- и вы увидите, будет ли он поднимать существенную часть таблицы или нет.

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


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