Style and typo fixes

Author: tigvarts

Makefile

@@ -1,13 +1,14 @@
 # contrib/aqo/Makefile
 
-MODULE_big = aqo
+EXTENSION = aqo
+PGFILEDESC = "AQO - adaptive query optimization"
+MODULES = aqo
+DATA = aqo--1.0.sql
 OBJS = aqo.o auto_tuning.o cardinality_estimation.o cardinality_hooks.o \
 hash.o machine_learning.o path_utils.o postprocessing.o preprocessing.o \
 selectivity_cache.o storage.o utils.o $(WIN32RES)
-EXTENSION = aqo
-DATA = aqo--1.0.sql
-PGFILEDESC = "aqo - adaptive query optimization"
 
+MODULE_big = aqo
 ifdef USE_PGXS
 PG_CONFIG = pg_config
 PGXS := $(shell $(PG_CONFIG) --pgxs)

README.md

@@ -1,9 +1,9 @@
 # Adaptive query optimization
 
 Adaptive query optimization is the extension of standard PostgreSQL cost-based
-query optimizer. Its basical principle is to use query execution statistics
+query optimizer. Its basic principle is to use query execution statistics
 for improving cardinality estimation. Experimental evaluation shows that this
-improvement sometimes provides an enourmously large speed-up for rather
+improvement sometimes provides an enormously large speed-up for rather
 complicated queries.
 
 This extension is under development now, but its main functionality is already
@@ -15,7 +15,7 @@ The module works with PostgreSQL 9.6.
 
 The module contains a patch and an extension. Patch has to be applied to the
 sources of PostgresSQL. Patch affects header files, that is why PostgreSQL
-must be rebuilded completelly after applying the patch ("make clean" and
+must be rebuilt completely after applying the patch ("make clean" and
 "make install").
 Extension has to be unpacked into contrib directory and then to be compiled and
 installed with "make install".
@@ -51,19 +51,19 @@ For handling workloads with dynamically generated query structures the forced
 mode "aqo.mode = 'forced'" is provided. We cannot guarantee performance
 improvement with this mode, but you may try it nevertheless.
 
-If you want to completelly control how PostgreSQL optimizes queries, use manual
+If you want to completely control how PostgreSQL optimizes queries, use manual
 mode "aqo.mode = 'manual'" and
 
 contrib/aqo/learn_queries.sh file_with_sql_queries.sql "psql -d YOUR_DATABASE"
 
-where file_with_sql_queries.sql is a textfile with queries on which aqo is
+where file_with_sql_queries.sql is a textfile with queries on which AQO is
 supposed to learn. Please use only SELECT queries file_with_sql_queries.sql.
-More sophisticated and convenient tool for aqo administration is in the
+More sophisticated and convenient tool for AQO administration is in the
 development now.
 
-If you want to freeze optimizer's behaviour (i. e. disable learning under
+If you want to freeze optimizer's behavior (i. e. disable learning under
 workload), use "UPDATE aqo_queries SET auto_tuning=false;".
-If you want to disable aqo for all queries, you may use
+If you want to disable AQO for all queries, you may use
 "UPDATE aqo_queries SET use_aqo=false, learn_aqo=false, auto_tuning=false;".
 
 ## Advanced tuning
@@ -81,34 +81,34 @@ structures: it tries to learn separately how to optimize different query types,
 and for dynamical query structure the query types are different, so it will
 consume a lot of memory and will not optimize any query properly.
 
-Forced mode forces aqo to ignore query types and optimize them together. On one
+Forced mode forces AQO to ignore query types and optimize them together. On one
 hand it lacks of intelligent tuning, so the performance for some queries may
 even decrease, on the other hand it may work for dynamic workload and consumes
-less memory than the intellignet mode. That is why you may want to use it.
+less memory than the intelligent mode. That is why you may want to use it.
 
 Each query type has its own optimization settings. You can find them in table
 aqo_queries.
 
-Auto_tuning setting identifies whether aqo module tries to tune other settings
-from aqo_queries for the query type. If the mode is intelligent, defalt value
-for new queries is true. If the mode is not intelligent, new queries are not
-appended to aqo_queries automatically, but you can also set auto_tuning variable
-to true manually.
+Auto_tuning setting identifies whether AQO module tries to tune other settings
+from aqo_queries for the query type on its own. If the mode is intelligent,
+default value for new queries is true. If the mode is not intelligent, new queries
+are not appended to aqo_queries automatically, but you can also set auto_tuning
+variable to true manually.
 
-Use_aqo setting shows whether aqo cardinalities prediction be used for next
-execution of such query type. Disabling of aqo usage is reasonable for that
-cases in which query execution time increases after applying aqo. It happens
+Use_aqo setting shows whether AQO cardinalities prediction be used for next
+execution of such query type. Disabling of AQO usage is reasonable for that
+cases in which query execution time increases after applying AQO. It happens
 sometimes because of cost models incompleteness.
 
-Learn_aqo setting shows whether aqo collects statistics for next execution of
+Learn_aqo setting shows whether AQO collects statistics for next execution of
 such query type. True value may have computational overheads, but it is
-essential when aqo model does not fit the data. It happens at the start of aqo
+essential when AQO model does not fit the data. It happens at the start of AQO
 for the new query type or when the data distribution in database is changed.
 
-Fspace_hash setting is for extra advanced aqo tuning. It may be changed manually
+Fspace_hash setting is for extra advanced AQO tuning. It may be changed manually
 to optimize a number of query types using the same model. It may decrease the
 amount of memory for models and even query execution performance, but also it
-may cause the bad aqo's behaviour, so please use it only if you know exactly
+may cause the bad AQO's behavior, so please use it only if you know exactly
 what you do.
 
 ## Statistics

aqo.c

@@ -120,6 +120,10 @@ _PG_fini(void)
 
 PG_FUNCTION_INFO_V1(invalidate_deactivated_queries_cache);
 
+/*
+ * Clears the cache of deactivated queries if the user changed aqo_queries
+ * manually.
+ */
 Datum
 invalidate_deactivated_queries_cache(PG_FUNCTION_ARGS)
 {

aqo.control

@@ -1,5 +1,5 @@
-# aqo extension
+# AQO extension
 comment = 'machine learning for cardinality estimation in optimizer'
 default_version = '1.0'
 module_pathname = '$libdir/aqo'
-relocatable = true
+relocatable = false

aqo.h

@@ -6,7 +6,7 @@
  * the execution statistics from previously executed queries is used.
  * Adaptive query optimization extends standard PostgreSQL cost-based query
  * optimization model.
- * This extension uses machine learning model builded over the collected
+ * This extension uses machine learning model built over the collected
  * statistics to improve cardinality estimations.
  *
  * The extension organized as follows.
@@ -27,29 +27,29 @@
  * Feature spaces are described by their hashes (an integer value).
  *
  * This extension presents three default modes:
- * "intelligent" mode tries to automatically tune aqo settings for the current
+ * "intelligent" mode tries to automatically tune AQO settings for the current
  * workload. It creates separate feature space for each new type of query
  * and then tries to improve the performance of such query type execution.
- * The automatical tuning may be manually deactivated for the given queries.
- * "forced" mode makes no difference between query types and use aqo for them
+ * The automatic tuning may be manually deactivated for the given queries.
+ * "forced" mode makes no difference between query types and use AQO for them
  * all in the similar way. It considers each new query type as linked to special
  * feature space called COMMON with hash 0.
- * "manual" mode ignores unknown query types. In this case aqo is completelly
- * configured manuallt by user.
+ * "manual" mode ignores unknown query types. In this case AQO is completely
+ * configured manually by user.
  * Current mode is stored in aqo.mode variable.
  *
  * User can manually set up his own feature space configuration
  * for query types by changing settings in table aqo_queries.
  *
  * Module preprocessing.c determines how to handle the given query.
- * This includes following questions: whether to use aqo for this query,
+ * This includes following questions: whether to use AQO for this query,
  * whether to use execution statistics of this query to update machine
  * learning models, to what feature space the query belongs to, and whether
  * this query allows using intelligence autotuning for three previous questions.
  * This data is stored in aqo_queries table. Also this module links
  * new query types to their feature spaces according to aqo.mode.
  *
- * If it is supposed to use aqo for given type of query, the extension hooks
+ * If it is supposed to use AQO for given type of query, the extension hooks
  * cardinality estimation functions in PostgreSQL. If the necessary statistics
  * for cardinality predictions using machine learning method is available,
  * the extension performs the prediction and returns its value. Otherwise it
@@ -59,12 +59,12 @@
  * for this part of work.
  *
  * If it is supposed to use execution statistics of given query for learning
- * models in aqo, the extension sets flag before execution to collect rows
+ * models in AQO, the extension sets flag before execution to collect rows
  * statistics. After query execution the collected statistics is proceed in
  * the extension and the update of related feature space models is performed.
  * Module postprocessing.c is responsible for this part of work.
  * Also it saves query execution time and cardinality qualities of queries
- * for further analisys by aqo and DBA.
+ * for further analysis by AQO and DBA.
  *
  * Note that extension is transaction-dependent. That means that user has to
  * commit transaction to make model updates visible for all backends.
@@ -101,7 +101,7 @@
  * Module storage.c is responsible for storage query settings and models
  * (i. e. all information which is used in extension).
  *
- * Copyright (c) 2016-2016, Postgres Professional
+ * Copyright (c) 2016-2017, Postgres Professional
  *
  * IDENTIFICATION
  *	  contrib/aqo/aqo.h
@@ -270,7 +270,7 @@ double aqo_get_parameterized_joinrel_size(PlannerInfo *root,
 								   SpecialJoinInfo *sjinfo,
 								   List *restrict_clauses);
 
-/* Extracting path infromation utilities */
+/* Extracting path information utilities */
 List *get_selectivities(PlannerInfo *root,
 				  List *clauses,
 				  int varRelid,
@@ -284,7 +284,7 @@ double predict_for_relation(List *restrict_clauses,
 					 List *selectivities,
 					 List *relids);
 
-/* Query execution statictics collecting hooks */
+/* Query execution statistics collecting hooks */
 void		aqo_ExecutorStart(QueryDesc *queryDesc, int eflags);
 void		aqo_copy_generic_path_info(PlannerInfo *root, Plan *dest, Path *src);
 void		learn_query_stat(QueryDesc *queryDesc);
@@ -297,7 +297,7 @@ List *OkNNr_learn(int matrix_rows, int matrix_cols,
 			double **matrix, double *targets,
 			double *nw_features, double nw_target);
 
-/* Automatical query tuning */
+/* Automatic query tuning */
 void		automatical_query_tuning(int query_hash, QueryStat * stat);
 
 /* Utilities */

auto_tuning.c

@@ -2,9 +2,9 @@
 
 /*****************************************************************************
  *
- *	AUTOMATICAL QUERY TUNING
+ *	AUTOMATIC QUERY TUNING
  *
- * This module automatically implements basic strategies of tuning aqo for best
+ * This module automatically implements basic strategies of tuning AQO for best
  * PostgreSQL performance.
  *
  *****************************************************************************/
@@ -44,7 +44,7 @@ converged_cq(double *elems, int nelems)
 
 	est = get_estimation(elems, nelems - 1);
 	return (est * 1.1 > elems[nelems - 1] || est + 0.1 > elems[nelems - 1]) &&
-			(est * 0.9 < elems[nelems - 1] || est - 0.1 < elems[nelems - 1]);
+		(est * 0.9 < elems[nelems - 1] || est - 0.1 < elems[nelems - 1]);
 }
 
 /*
@@ -55,26 +55,26 @@ converged_cq(double *elems, int nelems)
  * Now the workflow is quite simlple:
  *
  * Firstly, we run a new query type auto_tuning_window_size times without our
- * method to have an execution time statistics for such type of quieries.
- * Secondly, we run the query type with both aqo usage and aqo learning enabled
+ * method to have an execution time statistics for such type of queries.
+ * Secondly, we run the query type with both AQO usage and AQO learning enabled
  * until convergence.
  *
- * If aqo provides better execution time for the query type according to
+ * If AQO provides better execution time for the query type according to
  * collected statistics, we prefer to enable it, otherwise we prefer to disable
  * it.
  * In the stable workload case we perform an exploration. That means that with
- * some probability which depends on execution time with and without using aqo
+ * some probability which depends on execution time with and without using AQO
  * we run the slower method to check whether it remains slower.
  * Cardinality statistics collection is enabled by default in this mode.
  * If we find out that cardinality quality diverged during the exploration, we
- * return to step 2 and run the query type with both aqo usage and aqo learning
+ * return to step 2 and run the query type with both AQO usage and AQO learning
  * enabled until convergence.
  * If after auto_tuning_max_iterations steps we consider that for this query
- * it is better not to use aqo, we set auto_tuning, learn_aqo and use_aqo for
+ * it is better not to use AQO, we set auto_tuning, learn_aqo and use_aqo for
  * this query to false.
  */
 void
-automatical_query_tuning(int query_hash, QueryStat *stat)
+automatical_query_tuning(int query_hash, QueryStat * stat)
 {
 	double		unstability = auto_tuning_exploration;
 	double		t_aqo,
@@ -93,12 +93,12 @@ automatical_query_tuning(int query_hash, QueryStat *stat)
 	{
 		t_aqo = get_estimation(stat->execution_time_with_aqo,
 							   stat->execution_time_with_aqo_size) +
-				get_estimation(stat->planning_time_with_aqo,
-							   stat->planning_time_with_aqo_size);
+			get_estimation(stat->planning_time_with_aqo,
+						   stat->planning_time_with_aqo_size);
 		t_not_aqo = get_estimation(stat->execution_time_without_aqo,
 								   stat->execution_time_without_aqo_size) +
-					get_estimation(stat->planning_time_without_aqo,
-								   stat->planning_time_without_aqo_size);
+			get_estimation(stat->planning_time_without_aqo,
+						   stat->planning_time_without_aqo_size);
 		p_use = t_not_aqo / (t_not_aqo + t_aqo);
 		p_use = 1 / (1 + exp((p_use - 0.5) / unstability));
 		p_use -= 1 / (1 + exp(-0.5 / unstability));

cardinality_hooks.c

@@ -6,16 +6,16 @@
  *
  * This functions controls cardinality prediction in query optimization.
  * If use_aqo flag is false, then hooks just call default postgresql
- * cardinality estimator. Otherwise, they try to use aqo cardinality
+ * cardinality estimator. Otherwise, they try to use AQO cardinality
  * prediction engine.
  * If use_aqo flag in true, hooks generate set of all clauses and all
- * absolute relids used in the relation beeing builded and pass this
+ * absolute relids used in the relation being built and pass this
  * information to predict_for_relation function. Also these hooks compute
  * and pass to predict_for_relation marginal cardinalities for clauses.
- * If predict_for_relation returns non-negavite value, then hooks assume it
+ * If predict_for_relation returns non-negative value, then hooks assume it
  * to be true cardinality for given relation. Negative returned value means
  * refusal to predict cardinality. In this case hooks also use default
- * postgresql cardinality estimator.
+ * postgreSQL cardinality estimator.
  *
  *****************************************************************************/
 

hash.c

@@ -364,7 +364,7 @@ get_id_in_sorted_int_array(int val, int n, int *arr)
 
 /*
  * Returns class of equivalence for given argument hash or 0 if such hash
- * doen't belong to any equivalence class.
+ * does not belong to any equivalence class.
  */
 int
 get_arg_eclass(int arg_hash, int nargs, int *args_hash, int *eclass_hash)
@@ -499,7 +499,7 @@ perform_eclasses_join(List *clauselist, int nargs, int *args_hash)
 }
 
 /*
- * Constructs arg_hashes and arg_hash->eclass_hash maping for all non-constant
+ * Constructs arg_hashes and arg_hash->eclass_hash mapping for all non-constant
  * arguments of equivalence clauses of given clauselist.
  */
 void
@@ -565,7 +565,7 @@ has_consts(List *lst)
 /*
  * Returns pointer on the args list in clause or NULL.
  */
-List **
+List	  **
 get_clause_args_ptr(Expr *clause)
 {
 	switch (clause->type)

machine_learning.c

@@ -4,8 +4,8 @@
  *
  *	MACHINE LEARNING TECHNIQUES
  *
- * This module doesn't know anything about DBMS, cardinalities and all other
- * stuff. It learns matrixes, predicts values and is quite happy.
+ * This module does not know anything about DBMS, cardinalities and all other
+ * stuff. It learns matrices, predicts values and is quite happy.
  * The proposed method is designed for working with limited number of objects.
  * It is guaranteed that number of rows in the matrix will not exceed aqo_K
  * setting after learning procedure. This property also allows to adapt to
@@ -41,7 +41,7 @@ fs_distance(double *a, double *b, int len)
 double
 fs_similarity(double dist)
 {
-	return 1.0 / (0.1 + dist);
+	return 1.0 / (0.001 + dist);
 }
 
 /*

path_utils.c

@@ -73,8 +73,8 @@ get_path_clauses(Path *path, PlannerInfo *root, List **selectivities)
 	List	   *cur;
 	List	   *cur_sel = NIL;
 
-	if (selectivities)
-		*selectivities = NIL;
+	Assert(selectivities != NULL);
+	*selectivities = NIL;
 
 	if (path == NULL)
 		return NIL;