PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

PostgreSQL използва pg_trgm по-бавно от пълното сканиране

tldr:триграмите може да не са добри при търсене на шаблони, състоящи се от един знак, повтарящ се N пъти (като 666666 ), защото съществува само 1 нетерминална триграма и това може имат висока честота в пространството за търсене.

Когато се използва gin-index, растерното изображение на редовете е твърде голямо, за да се побере в паметта, така че вместо това се съхранява препратка към страници и базата данни трябва да извърши допълнително сканиране на тези страници. Ако броят на повторно проверените страници е малък, използването на индекса все още е от полза, но при голям брой повторно проверени страници индексът се представя зле. Това е подчертано от следните редове във вашия резултат за обяснение

   Recheck Cond: (x ~~* '%666666%'::text)
   Rows Removed by Index Recheck: 36257910
   Heap Blocks: exact=39064 lossy=230594

Проблемът е конкретно за вашия низ за търсене, т.е. 666666 , по отношение на данните от теста.

ако стартирате select pg_trgm('666666') , ще намерите:

        show_trgm        
-------------------------
 {"  6"," 66","66 ",666}
(1 row)

Първите 3 триграми дори няма да бъдат генерирани в подобен контекст (корекцията е предложена от потребител jjanes ) . Търсенето в индекса дава всички страници, съдържащи 666 . Можете да потвърдите това, като изпълните заявката за анализ на обяснение с ... ilike '%666%' , и получаване на същите Heap Blocks изведете както по-горе.

ако търсите с модела 123456 , ще видите, че се представя много по-добре, защото генерира по-голям набор от триграми за търсене:

              show_trgm              
-------------------------------------
 {"  1"," 12",123,234,345,456,"56 "}
(1 row)

На моята машина получавам следното:

|------------------------------------|
| pattern | pages rechecked          |
|         | exact | lossy  | total   |
|------------------------------------|
| 123456  |   600 |        |    600  |
| 666666  | 39454 | 230592 | 270046* |
|    666  | 39454 | 230592 | 270046* |
|------------------------------------|
*this is rougly 85% of the total # of pages used for the table 't'

Ето изхода за обяснение:

postgres=> explain analyze select * from t where x ~ '123456';
                                                        QUERY PLAN                                                        
--------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on t  (cost=90.75..18143.92 rows=5000 width=22) (actual time=110.962..113.509 rows=518 loops=1)
   Recheck Cond: (x ~ '123456'::text)
   Rows Removed by Index Recheck: 83
   Heap Blocks: exact=600
   ->  Bitmap Index Scan on t_x_idx  (cost=0.00..89.50 rows=5000 width=0) (actual time=110.868..110.868 rows=601 loops=1)
         Index Cond: (x ~ '123456'::text)
 Planning time: 0.703 ms
 Execution time: 113.564 ms
(8 rows)

postgres=> explain analyze select * from t where x ~ '666666';
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on t  (cost=54.75..18107.92 rows=5000 width=22) (actual time=137.143..18111.609 rows=462 loops=1)
   Recheck Cond: (x ~ '666666'::text)
   Rows Removed by Index Recheck: 36258389
   Heap Blocks: exact=39454 lossy=230592
   ->  Bitmap Index Scan on t_x_idx  (cost=0.00..53.50 rows=5000 width=0) (actual time=105.962..105.962 rows=593708 loops=1)
         Index Cond: (x ~ '666666'::text)
 Planning time: 0.420 ms
 Execution time: 18111.739 ms
(8 rows)

postgres=> explain analyze select * from t where x ~ '666';
                                                        QUERY PLAN                                                         
---------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on t  (cost=54.75..18107.92 rows=5000 width=22) (actual time=102.813..17285.086 rows=593708 loops=1)
   Recheck Cond: (x ~ '666'::text)
   Rows Removed by Index Recheck: 35665143
   Heap Blocks: exact=39454 lossy=230592
   ->  Bitmap Index Scan on t_x_idx  (cost=0.00..53.50 rows=5000 width=0) (actual time=96.100..96.100 rows=593708 loops=1)
         Index Cond: (x ~ '666'::text)
 Planning time: 0.500 ms
 Execution time: 17300.440 ms
(8 rows)


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Подреждане на релсите по поле за асоцииране

  2. Може ли все още да се чете от заключен ред [в Postgres]?

  3. Не може да се инсталира plpython3u - postgresql

  4. High Sierra + Python + Postgresql грешка:Незаконна инструкция:4

  5. Върнете същия резултат, когато се опитвате да намерите различни данни