|
| 1 | +# Adaptive query optimization |
| 2 | + |
| 3 | +Adaptive query optimization is the extension of standard PostgreSQL cost-based |
| 4 | +query optimizer. Its basic principle is to use query execution statistics |
| 5 | +for improving cardinality estimation. Experimental evaluation shows that this |
| 6 | +improvement sometimes provides an enormously large speed-up for rather |
| 7 | +complicated queries. |
| 8 | + |
| 9 | +## Installation |
| 10 | + |
| 11 | +In your db: |
| 12 | +CREATE EXTENSION aqo; |
| 13 | + |
| 14 | +and modify your postgresql.conf: |
| 15 | +shared_preload_libraries = 'aqo.so' |
| 16 | + |
| 17 | +It is essential that library is preloaded during server startup, because |
| 18 | +adaptive query optimization has to be enabled on per-database basis instead |
| 19 | +of per-connection. |
| 20 | + |
| 21 | +## Usage |
| 22 | + |
| 23 | +Note that the extension works bad with dynamically generated views. If they |
| 24 | +appear in workload, please use "aqo.mode='manual'". |
| 25 | + |
| 26 | +This extension has intelligent self-tuning mode. If you want to rely completely |
| 27 | +on it, just add line "aqo.mode = 'intelligent'" into your postgresql.conf. |
| 28 | + |
| 29 | +Now this mode may work not good for rapidly changing data and query |
| 30 | +distributions, so it is better to reset extension manually when that happens. |
| 31 | + |
| 32 | +Also please note that intelligent mode is not supposed to work with queries |
| 33 | +with dynamically generated structure. Dynamically generated constants are okay. |
| 34 | + |
| 35 | +For handling workloads with dynamically generated query structures the forced |
| 36 | +mode "aqo.mode = 'forced'" is provided. We cannot guarantee performance |
| 37 | +improvement with this mode, but you may try it nevertheless. |
| 38 | + |
| 39 | +If you want to completely control how PostgreSQL optimizes queries, use manual |
| 40 | +mode "aqo.mode = 'manual'" and |
| 41 | +contrib/aqo/learn_queries.sh file_with_sql_queries.sql "psql -d YOUR_DATABASE" |
| 42 | +where file_with_sql_queries.sql is a textfile with queries on which AQO is |
| 43 | +supposed to learn. Please use only SELECT queries file_with_sql_queries.sql. |
| 44 | +More sophisticated and convenient tool for AQO administration is in the |
| 45 | +development now. |
| 46 | +If you want to freeze optimizer's behavior (i. e. disable learning under |
| 47 | +workload), use "UPDATE aqo_queries SET auto_tuning=false;". |
| 48 | +If you want to disable AQO for all queries, you may use |
| 49 | +"UPDATE aqo_queries SET use_aqo=false, learn_aqo=false, auto_tuning=false;". |
| 50 | + |
| 51 | +## Advanced tuning |
| 52 | + |
| 53 | +To control query optimization we introduce for each query its type. |
| 54 | +We consider that queries belong to the same type if and only if they differ only |
| 55 | +in their constants. |
| 56 | +One can see an example of query corresponding to the specified query type |
| 57 | +in table aqo_query_texts. |
| 58 | +select * from aqo_query_texts; |
| 59 | + |
| 60 | +That is why intelligent mode does not work for dynamically generated query |
| 61 | +structures: it tries to learn separately how to optimize different query types, |
| 62 | +and for dynamical query structure the query types are different, so it will |
| 63 | +consume a lot of memory and will not optimize any query properly. |
| 64 | + |
| 65 | +Forced mode forces AQO to ignore query types and optimize them together. On one |
| 66 | +hand it lacks of intelligent tuning, so the performance for some queries may |
| 67 | +even decrease, on the other hand it may work for dynamic workload and consumes |
| 68 | +less memory than the intelligent mode. That is why you may want to use it. |
| 69 | + |
| 70 | +Each query type has its own optimization settings. You can find them in table |
| 71 | +aqo_queries. |
| 72 | + |
| 73 | +Auto_tuning setting identifies whether AQO module tries to tune other settings |
| 74 | +from aqo_queries for the query type on its own. If the mode is intelligent, |
| 75 | +default value for new queries is true. If the mode is not intelligent, new queries |
| 76 | +are not appended to aqo_queries automatically, but you can also set auto_tuning |
| 77 | +variable to true manually. |
| 78 | + |
| 79 | +Use_aqo setting shows whether AQO cardinalities prediction be used for next |
| 80 | +execution of such query type. Disabling of AQO usage is reasonable for that |
| 81 | +cases in which query execution time increases after applying AQO. It happens |
| 82 | +sometimes because of cost models incompleteness. |
| 83 | + |
| 84 | +Learn_aqo setting shows whether AQO collects statistics for next execution of |
| 85 | +such query type. True value may have computational overheads, but it is |
| 86 | +essential when AQO model does not fit the data. It happens at the start of AQO |
| 87 | +for the new query type or when the data distribution in database is changed. |
| 88 | + |
| 89 | +Fspace_hash setting is for extra advanced AQO tuning. It may be changed manually |
| 90 | +to optimize a number of query types using the same model. It may decrease the |
| 91 | +amount of memory for models and even query execution performance, but also it |
| 92 | +may cause the bad AQO's behavior, so please use it only if you know exactly |
| 93 | +what you do. |
| 94 | + |
| 95 | +## Statistics |
| 96 | + |
| 97 | +For forced and intelligent query modes, and for all tracked queries the |
| 98 | +statistics is collected. The statistics is cardinality quality, planning and |
| 99 | +execution time. For forced mode the statistics for all untracked query types |
| 100 | +is stored in common query type with hash 0. |
| 101 | + |
| 102 | +One can see the collected statistics in table aqo_query_stat. |
0 commit comments