|
Timestamp index
|
|||
---|---|---|---|
#18+
делаю create table xz(i int4,updatetime timestamp); CREATE INDEX test_indx_on_xz ON xz USING btree (updatetime); explain select * from xz where to_timestamp('DD.MM.YYYY','20.04.2003')<updatetime в итоге вижу тоже самое что и беэ индекса (enable_seqscan=off) че не так? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2003, 17:35 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
Интересо, почему именно поле timestamp для индекса, оно же не всегда уникально. По-моему лучше поле int4, опять же , если значения уникальны, либо ввести дополнительное поле, пойдёт и varchar. btree yдобнее для операции LIKE, >, <, = если преследуются другие цели, то прошу дополнении. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2003, 22:14 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
потамучта в основном запросы ... where updatetime>to_timestamp('DD.MM.YYYY HH24:MI:SS','12.03.2003 24:15:15').... поясни ,а причем тут поле varchar? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2003, 12:04 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
Varchar не причём, просто странно видеть индекс по timestamp, но это моё личное мнение. Попробуй по INT и посмотри Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2003, 14:50 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
тожесамое... эксперименты показали 1. select count(*) from xz ======= ~81000 2. select distinct updatetime from xz ======= 66 rows ---------- enable seqscan=on -------- 3. explain select * from xz where to_timestamp('DD.MM.YYYY','20.04.2003')<updatetime ========= seq scan ~= 2000. 4. explain select * from xz where to_timestamp('DD.MM.YYYY','20.04.2003')<updatetime order by updatetime ========= index scan ~= 4000 по другому никак неполучилось индекс заиспользовать.. даже при enable_seqscan=off походу что 81000 строк лучше перебрать так чем индекс использовать? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2003, 12:56 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
А можно таблицу сюда, посмотрю, покопаюсь, важ интересно стало что за ерунда. Там primary key есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2003, 13:33 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
мне кажется, to_timestamp('DD.MM.YYYY','20.04.2003') не воспринимается как константа и индекс поэтому не используется. попробуй как-нибудь по-другому это выражение оформить. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2003, 13:36 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
Тип, возвращаемый фунцкией to_timestamp - не timestamp. :-) # \dT timestamp List of data types Schema | Name | Description ------------+-----------------------------+--------------- pg_catalog | timestamp without time zone | date and time (1 row) # \df to_timestamp List of functions Result data type | Schema | Name | Argument data types --------------------------+------------+--------------+--------------------- timestamp with time zone | pg_catalog | to_timestamp | text, text (1 row) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2003, 17:21 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
CREATE TABLE public.z_71_37740 ( rowcode int4 NOT NULL, touropid int4, curortid int4, hotelid int4, katid int4, nviewid int4, ntypeid int4, nsizeid int4, ch1from int4, ch1to int4, ch2from int4, ch2to int4, foodid int4, nights int4, price int4, stopid int4 DEFAULT 0, currency int4, visa int4, aviaid int4, parama int4, tourid int4, spoid int4, spoorder int4, recordstatus int4 DEFAULT 1, updatetime timestamp DEFAULT ('now'::text)::timestamp(6) with time zone, CONSTRAINT pk_z_71_37740 PRIMARY KEY (rowcode) ) WITH OIDS; CREATE INDEX z_71_37740index ON z_71_37740 USING btree (nsizeid, nights, hotelid, curortid, touropid, katid, ch1from, ch1to, ch2from, ch2to, nviewid, ntypeid, foodid, aviaid); CREATE INDEX zUT_index ON z_71_37740 USING btree (updatetime); дамп таблички нада? :) ------------- а че "timestamp with time zone" ето разве не "timestamp" ??? а че есть "timestamp" без "time zone" ??? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2003, 18:53 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
- а че "timestamp with time zone" ето разве не "timestamp" ??? - Точно так!!! - а че есть "timestamp" без "time zone" ??? - Точно так!!! Сделайте create table xz(i int4,updatetime timestamp with timezone); или explain select * from xz where to_timestamp('DD.MM.YYYY','20.04.2003')::timestamp<updatetime; ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2003, 10:43 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
еще раз select count(*) from z_71_37740 ========= 81450 select count(*) from (select distinct updatetime from z_71_37740) as mt ========= 66 -------- enable seqscan=on ----------- explain select * from z_71_37740 where to_timestamp('DD.MM.YYYY','20.04.2003')::timestamp<updatetime; ========== Seq Scan on z_71_37740 (cost=0.00..2783.38 rows=27150 width=104) Filter: ((to_timestamp('DD.MM.YYYY'::text, '20.04.2003'::text))::timestamp without time zone < updatetime) ------- enable_seqscan=off ---------- explain select * from z_71_37740 where to_timestamp('DD.MM.YYYY','20.04.2003')::timestamp<updatetime; =========== Index Scan using z_time_indx on z_71_37740 (cost=0.00..3249.19 rows=27150 width=104) Index Cond: ((to_timestamp('DD.MM.YYYY'::text, '20.04.2003'::text))::timestamp without time zone < updatetime) ----------- итого ----------------- count(*)/distinc updatetime = 81450/66 Index Scan (cost=0.00..3249.19 ) (только при enable_seqscan=off) Seq Scan (cost=0.00..2783.38 ) ну типа теперь другой вопрос образовался. неужели на самом деле перебор по 81450 записям быстрее поиска по индексу из 66 узлов??? мож он неправильно cost считает??? или я чето недопонимаю ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2003, 11:35 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
в догонку explain analyse ^^^^^^^^ ---- enable_seqscan=off ----------- Index Scan using z_time_indx on z_71_37740 (cost=0.00..3249.19 rows=27150 width=104) (actual time=0.42..2320.10 rows=81450 loops=1) Index Cond: ((to_timestamp('DD.MM.YYYY'::text, '20.04.2003'::text))::timestamp without time zone < updatetime) Total runtime: 2882.00 msec ---- enable_seqscan=on ----------- Seq Scan on z_71_37740 (cost=0.00..2783.38 rows=27150 width=104) (actual time=0.17..2671.57 rows=81450 loops=1) Filter: ((to_timestamp('DD.MM.YYYY'::text, '20.04.2003'::text))::timestamp without time zone < updatetime) Total runtime: 3247.63 msec в итоге получается что pg неправильно считает cost при выборе между seqscan и indexscan .... у меня подобных таблиц много но с разным количеством строк.. на половине таблиц действительно seqscan был бы быстрее index scana, а на другой половине наоборот... а эти 400 msec мнебы пригодились , вроде немного но все равно ОБИДНА когда pg может быстрее , а делает как получится как научить pg правильно выбирать метод сканирования?? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2003, 12:04 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
vacuum analyze сделан? опечатка: у функции to_timestamp неправильный порядок аргументов. $ psql -c "create table ttt ( t1 timestamp )" $ perl -e 'print "begin;\n"; for my $y ( 1901 .. 1966 ) { for my $d ( 1..1234 ) { print "insert into ttt values ( to_timestamp( \x27$y\x27, \x27YYYY\x27 ) );\n" } } print "commit;\n"; ' | psql $ psql # create index t1 on ttt ( t1 ); # select count(*) from ttt; count ------- 81444 (1 row) # select count(*) from ( select distinct t1 from ttt ) as a; count ------- 66 (1 row) # create index t1 on ttt ( t1 ); # explain select * from ttt where to_timestamp('1933','YYYY')::timestamp < t1; QUERY PLAN ------------------------------------------------------------------------------------------ Seq Scan on ttt (cost=0.00..1825.27 rows=27148 width=8) Filter: ((to_timestamp('1933'::text, 'YYYY'::text))::timestamp without time zone < t1) # vacuum analyze ttt; # explain select * from ttt where to_timestamp('1933','YYYY')::timestamp < t1; QUERY PLAN ---------------------------------------------------------------------------------------------- Index Scan using t1 on ttt (cost=0.00..712.24 rows=27148 width=8) Index Cond: ((to_timestamp('1933'::text, 'YYYY'::text))::timestamp without time zone < t1) P.S.: # explain analyze select * from ttt where to_timestamp('1965','YYYY')::timestamp < t1; Total runtime: 5.31 msec # explain analyze select * from ttt where to_timestamp('1933','YYYY')::timestamp < t1; Total runtime: 275.59 msec # explain analyze select * from ttt where to_timestamp('1900','YYYY')::timestamp < t1; Total runtime: 555.48 msec # set enable_indexscan to off; # explain analyze select * from ttt where to_timestamp('1965','YYYY')::timestamp < t1; Total runtime: 1058.16 msec # explain analyze select * from ttt where to_timestamp('1933','YYYY')::timestamp < t1; Total runtime: 1208.25 msec # explain analyze select * from ttt where to_timestamp('1900','YYYY')::timestamp < t1; Total runtime: 906.10 msec ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2003, 12:24 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
у меня тоже самое аналогично выполняется но см: http://81.19.69.40/ может у меня в настройках чет не то? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2003, 13:58 |
|
Timestamp index
|
|||
---|---|---|---|
#18+
Провел ваш тест. Результаты почти такие же как и у вас. Не использует он индекс! :-( Могу лишь посоветовать поиграться с run-time параметрами CPU_*, DEFAULT_STATISTICS_TARGET. Однако у меня с наскока ничего не получилось. P.S.: Все-таки исправьте порядок аргументов в to_timestamp. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2003, 16:32 |
|
|
start [/forum/topic.php?fid=53&msg=32148745&tid=2008210]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 236ms |
total: | 378ms |
0 / 0 |