Функции в PostgreSQL. Проектирование структуры БД гарантийного ремонта, страница 2

"Seq Scan on predmet  (cost=0.00..21.79 rows=507 width=30) (actual time=0.394..1.867 rows=506 loops=1)"

"  Filter: (id > 500)"

"Total runtime: 2.877 ms"

shop=# EXPLAIN ANALYSE select * from predmet where id between 573 and 800;

"Seq Scan on predmet  (cost=0.00..24.34 rows=227 width=30) (actual time=0.441..1.329 rows=228 loops=1)"

"  Filter: ((id >= 573) AND (id <= 800))"

"Total runtime: 1.833 ms"

Мы видим, что с типом индекса BTREE, индекс использовался в 3х случаях, при операциях =, > и between. И при этом наблюдалось уменьшение времени выполнения запроса, приблизительно на 25%.

Индекс типа HASH, использовался в 2х случаях, при операции = и between. И при этом наблюдалось уменьшение времени выполнения запроса, приблизительно на 70%.

Без функционального индекса по полю типа char

shop=# EXPLAIN ANALYSE select * from predmet

where upper('name')='618196361233 42226';

"Result  (cost=0.00..19.23 rows=1 width=30) (actual time=0.003..0.003 rows=0 loops=1)"

"  One-Time Filter: false"

"  ->  Seq Scan on predmet  (cost=0.00..19.23 rows=1 width=30) (never executed)"

"Total runtime: 0.086 ms"

shop=# EXPLAIN ANALYSE select * from predmet

where upper('name')!='618196361233 42226';

"Seq Scan on predmet  (cost=0.00..19.23 rows=1023 width=30) (actual time=0.025..2.146 rows=1023 loops=1)"

"Total runtime: 4.057 ms"

С функциональным индексом по полю типа char

shop=# EXPLAIN ANALYSE select * from predmet where

upper('name')='618196361233 42226';    

"Result  (cost=0.00..19.23 rows=1 width=30) (actual time=0.003..0.003 rows=0 loops=1)"

"  One-Time Filter: false"

"  ->  Seq Scan on predmet  (cost=0.00..19.23 rows=1 width=30) (never executed)"

"Total runtime: 0.110 ms"                                         

shop=# EXPLAIN ANALYSE select * from products where

upper('name')!='679487264715 61403';

"Seq Scan on predmet  (cost=0.00..19.23 rows=1023 width=30) (actual time=0.030..2.158 rows=1023 loops=1)"

"Total runtime: 4.601 ms"

Используемый набор данных слишком мал для выводов об увеличении эффективности индекса.

На поле даты наложить ограничение таким образом, чтобы нельзя было ввести дату более сегодняшней.

remont=> alter table zakaz add constraint zakazedate check (data_z<=now()) ;

ALTER TABLE

remont=> insert into zakaz values ('2010-03-12', 2, 6);

ERROR:  new row for relation "zakaz" violates check constraint "zakazedate"

STATEMENT:  insert into zakaz values ('2010-03-12', 2, 6);

ERROR:  new row for relation "zakaz" violates check constraint "zakazedate"

remont=> select * from zakaz;

   data_z   | kol_p | id

------------+-------+----

 2008-03-12 |     2 |  1

 2008-06-22 |     3 |  2

 2008-06-15 |     1 |  3

 2008-10-31 |     2 |  4

 2008-11-01 |     3 |  5

 2008-03-12 |     2 |  1