PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Postgresql join_collapse_limit i czas na planowanie zapytań

Nowa wersja PostgreSQL 9.4 (jeszcze nie wydana w momencie pisania tego tekstu) doda czas planowania do EXPLAIN i EXPLAIN ANALYZE , dzięki czemu będziesz mógł z nich korzystać.

W przypadku starszych wersji Twoje założenie jest słuszne, lepszym sposobem określenia czasu planowania jest wykonanie prostego EXPLAIN (bez ANALYZE ) i sprawdzanie czasu, jaki zajęło, w psql możesz to zrobić, włączając \timing (Zazwyczaj robię to w ~/.psqlrc ).

Zespół hakerów PostgreSQL dyskutował już o podniesieniu go do wyższych wartości . Ale wygląda na to, że nie mogą zagwarantować, że będzie to dobre we wszystkich przypadkach.

Problem polega na tym, że planowanie znalezienia najlepszej kolejności złączenia dla N tabele przyjmują O(N!) (czynnikowe) podejście. A więc liczby, które podbiły są bardzo wysokie, można to łatwo zobaczyć za pomocą następującego zapytania:

$ SELECT i, (i)! AS num_comparisons FROM generate_series(8, 20) i;
 i  |   num_comparisons   
----+---------------------
  8 |               40320
  9 |              362880
 10 |             3628800
 11 |            39916800
 12 |           479001600
 13 |          6227020800
 14 |         87178291200
 15 |       1307674368000
 16 |      20922789888000
 17 |     355687428096000
 18 |    6402373705728000
 19 |  121645100408832000
 20 | 2432902008176640000
(13 rows)

Jak widać, przy domyślnej wartości 8 wykonujemy najwyżej około 40 tys. porównań, 10, które zaproponowałeś, powoduje przejście do 3M, co wciąż nie jest zbyt duże dla nowoczesnych komputerów, ale kolejne wartości zaczynają być zbyt duże, po prostu rosną zbyt szybko, 20 jest po prostu szalone (21! nie mieści się nawet 64-bitowej liczby całkowitej).

Oczywiście czasami możesz ustawić go na większe wartości, takie jak 16, co mogłoby (teoretycznie) stanowić około 20 bilionów porównań i nadal mieć bardzo dobry czas planowania, ponieważ PostgreSQL przecina niektóre ścieżki podczas planowania i nie potrzebuje do zawsze sprawdzam wszystkie zamówienia, ale założenie, że tak będzie zawsze i ustawienie tak wysokich wartości jako domyślne, nie wydaje mi się dobrym podejściem. W przyszłości może pojawić się nieoczekiwane zapytanie, które spowoduje, że przejdzie do sprawdzenia wszystkich zamówień, a następnie pojawi się tylko jedno zapytanie, które spowoduje wyłączenie serwera.

Z mojego doświadczenia zakładam, że 10 jest wartością domyślną w każdej instalacji na dobrych serwerach, niektóre z nich używam nawet 12. Polecam ustawić ją na 10, jeśli chcesz, a czasami spróbuj ustawić ją wyżej ( Nie przekroczyłbym 12) i nadal monitoruję (dokładnie), aby zobaczyć, jak się zachowuje.




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Poprawne ustawienie puli połączeń z bazą danych database.yml dla jednowątkowych aplikacji Rails

  2. Postgresql :Jak wybrać pierwsze n procent (%) wpisów z każdej grupy/kategorii?

  3. Wzorce i modyfikatory szablonów do formatowania daty/godziny w PostgreSQL

  4. Jak zmienić typ kolumny ze zmiennej na liczbę całkowitą za pomocą sqlalchemy-migrate?

  5. Po co określać długość dla różnych typów znaków?