Простой тест.
Вот у вас есть страница которая принимает на вход id чего либо (цело число)
и идет в таблицу за этим id, и вы даже проверили что у вас на входе число а не черте что.
Далее test case:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
postgres=# create table test as select id from generate_series(1, 100000) as g(id);
SELECT 100000
postgres=# alter table test add primary key (id);
ALTER TABLE
postgres=# analyze test;
ANALYZE
postgres=# explain analyze select * from test where id=100;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
Index Only Scan using test_pkey on test (cost=0.29..8.31 rows=1 width=4) (actual time=0.050..0.052 rows=1 loops=1)
Index Cond: (id = 100)
Heap Fetches: 1
Planning time: 0.349 ms
Execution time: 0.102 ms
пока все ок... а что будет если на вход реально длинное число задать:
1.
2.
3.
4.
5.
6.
7.
8.
postgres=# explain analyze select * from test where id=100000000000000000000;
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..1893.00 rows=500 width=4) (actual time=18.581..18.581 rows=0 loops=1)
Filter: ((id)::numeric = 100000000000000000000::numeric)
Rows Removed by Filter: 100000
Planning time: 0.159 ms
Execution time: 18.613 ms
Оооps, а получили то мы upcast к numeric и как итог полный seq scan по таблице, а теперь представим себе что у вас в таблице не 100.000 строк а 100M и размер под 10-100Gb, и что будет с дисками и с процессором у вас если кто то десяток таких страниц откроет.
И что грустно мне заявили что working as designed.
PS: использование placeholders при отключении server side prepared statement - не спасает.
--
Проект с базой но без DBA все равно что автопарк без штатного автомеханика. Ездит пока все не сломается.
http://www.postgresql-consulting.ru/services/
