README.md

   1 # pg\_hint\_plan 1.4
   2
   3 1. [Synopsis](#synopsis)
   4 1. [Description](#description)
   5 1. [The hint table](#the-hint-table)
   6 1. [Installation](#installation)
   7 1. [Unistallation](#unistallation)
   8 1. [Details in hinting](#details-in-hinting)
   9 1. [Errors](#errors)
  10 1. [Functional limitations](#functional-limitations)
  11 1. [Requirements](#requirements)
  12 1. [Hints list](#hints-list)
  13
  14
  15 ## Synopsis
  16
  17 `pg_hint_plan` makes it possible to tweak PostgreSQL execution plans using so-called "hints" in SQL comments, like `/*+ SeqScan(a) */`.
  18
  19 PostgreSQL uses a cost-based optimizer, which utilizes data statistics, not static rules. The planner (optimizer) esitimates costs of each possible execution plans for a SQL statement then the execution plan with the lowest cost finally be executed. The planner does its best to select the best best execution plan, but is not always perfect, since it doesn't count some properties of the data, for example, correlation between columns.
  20
  21
  22 ## Description
  23
  24 ### Basic Usage
  25
  26 `pg_hint_plan` reads hinting phrases in a comment of special form given with the target SQL statement. The special form is beginning by the character sequence `"/\*+"` and ends with `"\*/"`. Hint phrases are consists of hint name and following parameters enclosed by parentheses and delimited by spaces. Each hinting phrases can be delimited by new lines for readability.
  27
  28 In the example below, hash join is selected as the joning method and scanning `pgbench_accounts` by sequential scan method.
  29
  30 <pre>
  31 postgres=# /*+
  32 postgres*#    <b>HashJoin(a b)</b>
  33 postgres*#    <b>SeqScan(a)</b>
  34 postgres*#  */
  35 postgres-# EXPLAIN SELECT *
  36 postgres-#    FROM pgbench_branches b
  37 postgres-#    JOIN pgbench_accounts a ON b.bid = a.bid
  38 postgres-#   ORDER BY a.aid;
  39                                         QUERY PLAN
  40 ---------------------------------------------------------------------------------------
  41     Sort  (cost=31465.84..31715.84 rows=100000 width=197)
  42     Sort Key: a.aid
  43     ->  <b>Hash Join</b>  (cost=1.02..4016.02 rows=100000 width=197)
  44             Hash Cond: (a.bid = b.bid)
  45             ->  <b>Seq Scan on pgbench_accounts a</b>  (cost=0.00..2640.00 rows=100000 width=97)
  46             ->  Hash  (cost=1.01..1.01 rows=1 width=100)
  47                 ->  Seq Scan on pgbench_branches b  (cost=0.00..1.01 rows=1 width=100)
  48 (7 rows)
  49
  50 postgres=#
  51 </pre>
  52
  53 ## The hint table
  54
  55 Hints are described in a comment in a special form in the above section. This is inconvenient in the case where queries cannot be edited. In the case hints can be placed in a special table named `"hint_plan.hints"`. The table consists of the following columns.
  56
  57 |       column        |                                                                                         description                                                                                         |
  58 |:--------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
  59 | `id`                | Unique number to identify a row for a hint. This column is filled automatically by sequence.                                                                                                |
  60 | `norm_query_string` | A pattern matches to the query to be hinted. Constants in the query have to be replace with '?' as in the following example. White space is significant in the pattern.                     |
  61 | `application_name`  | The value of `application_name` of sessions to apply the hint. The hint in the example below applies to sessions connected from psql. An empty string means sessions of any `application_name`. |
  62 | `hints`             | Hint phrase. This must be a series of hints excluding surrounding comment marks.                                                                                                            |
  63
  64 The following example shows how to operate with the hint table.
  65
  66     postgres=# INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
  67     postgres-#     VALUES (
  68     postgres(#         'EXPLAIN (COSTS false) SELECT * FROM t1 WHERE t1.id = ?;',
  69     postgres(#         '',
  70     postgres(#         'SeqScan(t1)'
  71     postgres(#     );
  72     INSERT 0 1
  73     postgres=# UPDATE hint_plan.hints
  74     postgres-#    SET hints = 'IndexScan(t1)'
  75     postgres-#  WHERE id = 1;
  76     UPDATE 1
  77     postgres=# DELETE FROM hint_plan.hints
  78     postgres-#  WHERE id = 1;
  79     DELETE 1
  80     postgres=#
  81
  82 The hint table is owned by the creator user and having the default privileges at the time of creation. during `CREATE EXTENSION`. Table hints are prioritized over comment hits.
  83
  84 ### The types of hints
  85
  86 Hinting phrases are classified into six types based on what kind of object and how they can affect planning. Scanning methods, join methods, joining order, row number correction, parallel query, and GUC setting. You will see the lists of hint phrases of each type in [Hint list](#hints-list).
  87
  88 #### Hints for scan methods
  89
  90 Scan method hints enforce specific scanning method on the target table. `pg_hint_plan` recognizes the target table by alias names if any. They are `SeqScan`, `IndexScan` and so on in this kind of hint.
  91
  92 Scan hints are effective on ordinary tables, inheritance tables, UNLOGGED tables, temporary tables and system catalogs. External (foreign) tables, table functions, VALUES clause, CTEs, views and subquiries are not affected.
  93
  94     postgres=# /*+
  95     postgres*#     SeqScan(t1)
  96     postgres*#     IndexScan(t2 t2_pkey)
  97     postgres*#  */
  98     postgres-# SELECT * FROM table1 t1 JOIN table table2 t2 ON (t1.key = t2.key);
  99
 100 #### Hints for join methods
 101
 102 Join method hints enforce the join methods of the joins involving specified tables.
 103
 104 This can affect on joins only on ordinary tables, inheritance tables, UNLOGGED tables, temporary tables, external (foreign) tables, system catalogs, table functions, VALUES command results and CTEs are allowed to be in the parameter list. But joins on views and sub query are not affected.
 105
 106 #### Hint for joining order
 107
 108 This hint "Leading" enforces the order of join on two or more tables. There are two ways of enforcing. One is enforcing specific order of joining but not restricting direction at each join level. Another enfoces join direction additionaly. Details are seen in the [hint list](#hints-list) table.
 109
 110     postgres=# /*+
 111     postgres*#     NestLoop(t1 t2)
 112     postgres*#     MergeJoin(t1 t2 t3)
 113     postgres*#     Leading(t1 t2 t3)
 114     postgres*#  */
 115     postgres-# SELECT * FROM table1 t1
 116     postgres-#     JOIN table table2 t2 ON (t1.key = t2.key)
 117     postgres-#     JOIN table table3 t3 ON (t2.key = t3.key);
 118
 119 #### Hint for row number correction
 120
 121 This hint "Rows" corrects row number misestimation of joins that comes from restrictions of the planner.
 122
 123     postgres=# /*+ Rows(a b #10) */ SELECT... ; Sets rows of join result to 10
 124     postgres=# /*+ Rows(a b +10) */ SELECT... ; Increments row number by 10
 125     postgres=# /*+ Rows(a b -10) */ SELECT... ; Subtracts 10 from the row number.
 126     postgres=# /*+ Rows(a b *10) */ SELECT... ; Makes the number 10 times larger.
 127
 128 #### Hint for parallel plan
 129
 130 This hint `Parallel` enforces parallel execution configuration on scans. The third parameter specifies the strength of enfocement. `soft` means that `pg_hint_plan` only changes `max_parallel_worker_per_gather` and leave all others to planner. `hard` changes other planner parameters so as to forcibly apply the number. This can affect on ordinary tables, inheritnce parents, unlogged tables and system catalogues. External tables, table functions, values clause, CTEs, views and subqueries are not affected. Internal tables of a view can be specified by its real name/alias as the target object. The following example shows that the query is enforced differently on each table.
 131
 132     postgres=# explain /*+ Parallel(c1 3 hard) Parallel(c2 5 hard) */
 133            SELECT c2.a FROM c1 JOIN c2 ON (c1.a = c2.a);
 134                                       QUERY PLAN
 135     -------------------------------------------------------------------------------
 136      Hash Join  (cost=2.86..11406.38 rows=101 width=4)
 137        Hash Cond: (c1.a = c2.a)
 138        ->  Gather  (cost=0.00..7652.13 rows=1000101 width=4)
 139              Workers Planned: 3
 140              ->  Parallel Seq Scan on c1  (cost=0.00..7652.13 rows=322613 width=4)
 141        ->  Hash  (cost=1.59..1.59 rows=101 width=4)
 142              ->  Gather  (cost=0.00..1.59 rows=101 width=4)
 143                    Workers Planned: 5
 144                    ->  Parallel Seq Scan on c2  (cost=0.00..1.59 rows=59 width=4)
 145
 146     postgres=# EXPLAIN /*+ Parallel(tl 5 hard) */ SELECT sum(a) FROM tl;
 147                                         QUERY PLAN
 148     -----------------------------------------------------------------------------------
 149      Finalize Aggregate  (cost=693.02..693.03 rows=1 width=8)
 150        ->  Gather  (cost=693.00..693.01 rows=5 width=8)
 151              Workers Planned: 5
 152              ->  Partial Aggregate  (cost=693.00..693.01 rows=1 width=8)
 153                    ->  Parallel Seq Scan on tl  (cost=0.00..643.00 rows=20000 width=4)
 154
 155 #### GUC parameters temporarily setting
 156
 157 `Set` hint changes GUC parameters just while planning. GUC parameter shown in [Query Planning](http://www.postgresql.org/docs/current/static/runtime-config-query.html) can have the expected effects on planning unless any other hint conflicts with the planner method configuration parameters. The last one among hints on the same GUC parameter makes effect. [GUC parameters for `pg_hint_plan`](#guc-parameters-for-pg_hint_plan) are also settable by this hint but it won't work as your expectation. See [Restrictions](#restrictions) for details.
 158
 159     postgres=# /*+ Set(random_page_cost 2.0) */
 160     postgres-# SELECT * FROM table1 t1 WHERE key = 'value';
 161     ...
 162
 163 ### GUC parameters for `pg_hint_plan`
 164
 165 GUC parameters below affect the behavior of `pg_hint_plan`.
 166
 167 |         Parameter name         |                                               Description                                                             | Default   |
 168 |:-------------------------------|:----------------------------------------------------------------------------------------------------------------------|:----------|
 169 | `pg_hint_plan.enable_hint`       | True enbles `pg_hint_plan`.                                                                                         | `on`      |
 170 | `pg_hint_plan.enable_hint_table` | True enbles hinting by table. `true` or `false`.                                                                    | `off`     |
 171 | `pg_hint_plan.parse_messages`    | Specifies the log level of hint parse error. Valid values are `error`, `warning`, `notice`, `info`, `log`, `debug`. | `INFO`    |
 172 | `pg_hint_plan.debug_print`       | Controls debug print and verbosity. Valid vaiues are `off`, `on`, `detailed` and `verbose`.                         | `off`     |
 173 | `pg_hint_plan.message_level`     | Specifies message level of debug print. Valid values are `error`, `warning`, `notice`, `info`, `log`, `debug`.      | `INFO`    |
 174
 175 ## Installation
 176
 177 This section describes the installation steps.
 178
 179 ### building binary module
 180
 181 Simply run `make` at the top of the source tree, then `make install` as an appropriate user. The `PATH` environment variable should be set properly for the target PostgreSQL for this process.
 182
 183     $ tar xzvf pg_hint_plan-1.x.x.tar.gz
 184     $ cd pg_hint_plan-1.x.x
 185     $ make
 186     $ su
 187     # make install
 188
 189 ### Loading `pg_hint_plan`
 190
 191 Basically `pg_hint_plan` does not require `CREATE EXTENSION`. Simply loading it by `LOAD` command will activate it and of course you can load it globally by setting `shared_preload_libraries` in `postgresql.conf`. Or you might be interested in `ALTER USER SET`/`ALTER DATABASE SET` for automatic loading for specific sessions.
 192
 193     postgres=# LOAD 'pg_hint_plan';
 194     LOAD
 195     postgres=#
 196
 197 Do `CREATE EXTENSION` and `SET pg_hint_plan.enable_hint_tables TO on` if you are planning to hint tables.
 198
 199 ## Unistallation
 200
 201 `make uninstall` in the top directory of source tree will uninstall the installed files if you installed from the source tree and it is left available.
 202
 203     $ cd pg_hint_plan-1.x.x
 204     $ su
 205     # make uninstall
 206
 207 ## Details in hinting
 208
 209 #### Syntax and placement
 210
 211 `pg_hint_plan` reads hints from only the first block comment and any characters except alphabets, digits, spaces, underscores, commas and parentheses stops parsing immediately. In the following example `HashJoin(a b)` and `SeqScan(a)` are parsed as hints but `IndexScan(a)` and `MergeJoin(a b)` are not.
 212
 213     postgres=# /*+
 214     postgres*#    HashJoin(a b)
 215     postgres*#    SeqScan(a)
 216     postgres*#  */
 217     postgres-# /*+ IndexScan(a) */
 218     postgres-# EXPLAIN SELECT /*+ MergeJoin(a b) */ *
 219     postgres-#    FROM pgbench_branches b
 220     postgres-#    JOIN pgbench_accounts a ON b.bid = a.bid
 221     postgres-#   ORDER BY a.aid;
 222                                           QUERY PLAN
 223     ---------------------------------------------------------------------------------------
 224      Sort  (cost=31465.84..31715.84 rows=100000 width=197)
 225        Sort Key: a.aid
 226        ->  Hash Join  (cost=1.02..4016.02 rows=100000 width=197)
 227              Hash Cond: (a.bid = b.bid)
 228              ->  Seq Scan on pgbench_accounts a  (cost=0.00..2640.00 rows=100000 width=97)
 229              ->  Hash  (cost=1.01..1.01 rows=1 width=100)
 230                    ->  Seq Scan on pgbench_branches b  (cost=0.00..1.01 rows=1 width=100)
 231     (7 rows)
 232
 233     postgres=#
 234
 235 #### Using with PL/pgSQL
 236
 237 `pg_hint_plan` works for queries in PL/pgSQL scripts with some restrictions.
 238
 239 -   Hints affect only on the following kind of queires.
 240     -   Queries that returns one row. (`SELECT`, `INSERT`, `UPDATE` and `DELETE`)
 241     -   Queries that returns multiple rows. (`RETURN QUERY`)
 242     -   Dynamic SQL statements. (`EXECUTE`)
 243     -   Cursor open. (`OPEN`)
 244     -   Loop over result of a query (`FOR`)
 245 -   A hint comment have to be placed after the first word in a query as the following since preceding comments are not sent as a part of the query.
 246
 247         postgres=# CREATE FUNCTION hints_func(integer) RETURNS integer AS $$
 248         postgres$# DECLARE
 249         postgres$#     id  integer;
 250         postgres$#     cnt integer;
 251         postgres$# BEGIN
 252         postgres$#     SELECT /*+ NoIndexScan(a) */ aid
 253         postgres$#         INTO id FROM pgbench_accounts a WHERE aid = $1;
 254         postgres$#     SELECT /*+ SeqScan(a) */ count(*)
 255         postgres$#         INTO cnt FROM pgbench_accounts a;
 256         postgres$#     RETURN id + cnt;
 257         postgres$# END;
 258         postgres$# $$ LANGUAGE plpgsql;
 259
 260 #### Letter case in the object names
 261
 262 Unlike the way PostgreSQL handles object names, `pg_hint_plan` compares bare object names in hints against the database internal object names in case sensitive way. Therefore an object name TBL in a hint matches only "TBL" in database and does not match any unquoted names like TBL, tbl or Tbl.
 263
 264 #### Escaping special chacaters in object names
 265
 266 The objects as the hint parameter should be enclosed by double quotes if they includes parentheses, double quotes and white spaces. The escaping rule is the same as PostgreSQL.
 267
 268 ### Distinction between multiple occurances of a table
 269
 270 `pg_hint_plan` identifies the target object by using aliases if exists. This behavior is usable to point a specific occurance among multiple occurances of one table.
 271
 272     postgres=# /*+ HashJoin(t1 t1) */
 273     postgres-# EXPLAIN SELECT * FROM s1.t1
 274     postgres-# JOIN public.t1 ON (s1.t1.id=public.t1.id);
 275     INFO:  hint syntax error at or near "HashJoin(t1 t1)"
 276     DETAIL:  Relation name "t1" is ambiguous.
 277     ...
 278     postgres=# /*+ HashJoin(pt st) */
 279     postgres-# EXPLAIN SELECT * FROM s1.t1 st
 280     postgres-# JOIN public.t1 pt ON (st.id=pt.id);
 281                                  QUERY PLAN
 282     ---------------------------------------------------------------------
 283      Hash Join  (cost=64.00..1112.00 rows=28800 width=8)
 284        Hash Cond: (st.id = pt.id)
 285        ->  Seq Scan on t1 st  (cost=0.00..34.00 rows=2400 width=4)
 286        ->  Hash  (cost=34.00..34.00 rows=2400 width=4)
 287              ->  Seq Scan on t1 pt  (cost=0.00..34.00 rows=2400 width=4)
 288
 289 #### Underlying tables of views or rules
 290
 291 Hints are not applicable on views itself, but they can affect the queries within if the object names match the object names in the expanded query on the view. Assigning aliases to the tables in a view enables them to be manipulated from outside the view.
 292
 293     postgres=# CREATE VIEW v1 AS SELECT * FROM t2;
 294     postgres=# EXPLAIN /*+ HashJoin(t1 v1) */
 295               SELECT * FROM t1 JOIN v1 ON (c1.a = v1.a);
 296                                 QUERY PLAN
 297     ------------------------------------------------------------------
 298      Hash Join  (cost=3.27..18181.67 rows=101 width=8)
 299        Hash Cond: (t1.a = t2.a)
 300        ->  Seq Scan on t1  (cost=0.00..14427.01 rows=1000101 width=4)
 301        ->  Hash  (cost=2.01..2.01 rows=101 width=4)
 302              ->  Seq Scan on t2  (cost=0.00..2.01 rows=101 width=4)
 303
 304 #### Inheritance tables
 305
 306 Hints can point only the parent of an inheritance tables and the hint affect all the inheritance. Hints simultaneously point directly to children are not in effect.
 307
 308 #### Hinting on multistatements
 309
 310 One multistatement can have exactly one hint comment and the hints affects all of the individual statement in the multistatement. Notice that the seemingly multistatement on the interactive interface of psql is internally a sequence of single statements so hints affects only on the statement just following.
 311
 312 #### VALUES expressions
 313
 314 `VALUES` expressions in `FROM` clause are named as `*VALUES*` internally so it is hintable if it is the only `VALUES` in a query. Two or more `VALUES` expressions in a query seem distinguishable looking at its explain result. But in reality, it is merely a cosmetic and they are not distinguishable.
 315
 316     postgres=# /*+ MergeJoin(*VALUES*_1 *VALUES*) */
 317           EXPLAIN SELECT * FROM (VALUES (1, 1), (2, 2)) v (a, b)
 318           JOIN (VALUES (1, 5), (2, 8), (3, 4)) w (a, c) ON v.a = w.a;
 319     INFO:  pg_hint_plan: hint syntax error at or near "MergeJoin(*VALUES*_1 *VALUES*) "
 320     DETAIL:  Relation name "*VALUES*" is ambiguous.
 321                                    QUERY PLAN
 322     -------------------------------------------------------------------------
 323      Hash Join  (cost=0.05..0.12 rows=2 width=16)
 324        Hash Cond: ("*VALUES*_1".column1 = "*VALUES*".column1)
 325        ->  Values Scan on "*VALUES*_1"  (cost=0.00..0.04 rows=3 width=8)
 326        ->  Hash  (cost=0.03..0.03 rows=2 width=8)
 327              ->  Values Scan on "*VALUES*"  (cost=0.00..0.03 rows=2 width=8)
 328
 329 ### Subqueries
 330
 331 Subqueries in the following context occasionally can be hinted using the name `ANY_subquery`.
 332
 333     IN (SELECT ... {LIMIT | OFFSET ...} ...)
 334     = ANY (SELECT ... {LIMIT | OFFSET ...} ...)
 335     = SOME (SELECT ... {LIMIT | OFFSET ...} ...)
 336
 337 For these syntaxes, planner internally assigns the name to the subquery when planning joins on tables including it, so join hints are applicable on such joins using the implicit name as the following.
 338
 339     postgres=# /*+HashJoin(a1 ANY_subquery)*/
 340     postgres=# EXPLAIN SELECT *
 341     postgres=#    FROM pgbench_accounts a1
 342     postgres=#   WHERE aid IN (SELECT bid FROM pgbench_accounts a2 LIMIT 10);
 343                                              QUERY PLAN
 344
 345     ---------------------------------------------------------------------------------------------
 346      Hash Semi Join  (cost=0.49..2903.00 rows=1 width=97)
 347        Hash Cond: (a1.aid = a2.bid)
 348        ->  Seq Scan on pgbench_accounts a1  (cost=0.00..2640.00 rows=100000 width=97)
 349        ->  Hash  (cost=0.36..0.36 rows=10 width=4)
 350              ->  Limit  (cost=0.00..0.26 rows=10 width=4)
 351                    ->  Seq Scan on pgbench_accounts a2  (cost=0.00..2640.00 rows=100000 width=4)
 352
 353 #### Using `IndexOnlyScan` hint
 354
 355 Index scan may unexpectedly performed on another index when the index specifed in IndexOnlyScan hint cannot perform index only scan.
 356
 357 #### Behavior of `NoIndexScan`
 358
 359 `NoIndexScan` hint involes `NoIndexOnlyScan`.
 360
 361 #### Parallel hint and `UNION`
 362
 363 A `UNION` can run in parallel only when all underlying subqueries are parallel-safe. Conversely enforcing parallel on any of the subqueries let a parallel-executable `UNION` run in parallel. Meanwhile, a parallel hint with zero workers hinhibits a scan from executed in parallel.
 364
 365 #### Setting `pg_hint_plan` parameters by Set hints
 366
 367 `pg_hint_plan` parameters change the behavior of itself so some parameters doesn't work as expected.
 368
 369 -   Hints to change `enable_hint`, `enable_hint_tables` are ignored even though they are reported as "used hints" in debug logs.
 370 -   Setting `debug_print` and `message_level` works from midst of the processing of the target query.
 371
 372 ## Errors
 373
 374 `pg_hint_plan` stops parsing on any error and uses hints already parsed on the most cases. Following are the typical errors.
 375
 376 #### Syntax errors
 377
 378 Any syntactical errors or wrong hint names are reported as a syntax error. These errors are reported in the server log with the message level specified by `pg_hint_plan.message_level` if `pg_hint_plan.debug_print` is on and above.
 379
 380 #### Object misspecifications
 381
 382 Object misspecifications result in silent ignorance of the hints. This kind of error is reported as "not used hints" in the server log by the same condition as syntax errors.
 383
 384 #### Redundant or conflicting hints
 385
 386 The last hint will be active when redundant hints or hints conflicting with each other. This kind of error is reported as "duplication hints" in the server log by the same condition to syntax errors.
 387
 388 #### Nested comments
 389
 390 Hint comment cannot include another block comment within. If `pg_hint_plan` finds it, differently from other erros, it stops parsing and abandans all hints already parsed. This kind of error is reported in the same manner as other errors.
 391
 392 ## Functional limitations
 393
 394 #### Influences of some of planner GUC parameters
 395
 396 The planner does not try to consider joining order for FROM clause entries more than `from_collapse_limit`. `pg_hint_plan` cannot affect joining order as expected for the case.
 397
 398 #### Hints trying to enforce unexecutable plans
 399
 400 Planner chooses any executable plans when the enforced plan cannot be executed.
 401
 402 -   `FULL OUTER JOIN` to use nested loop
 403 -   To use indexes that does not have columns used in quals
 404 -   To do TID scans for queries without ctid conditions
 405
 406 #### Queries in ECPG
 407
 408 ECPG removes comments in queries written as embedded SQLs so hints cannot be passed form those queries. The only exception is that `EXECUTE` command passes given string unmodifed. Please consider hint tables in the case.
 409
 410 #### Work with `pg_stat_statements`
 411
 412 `pg_stat_statements` generates a query id ignoring comments. As the result, the identical queries with different hints are summarized as the same query.
 413
 414 ## Requirements
 415
 416 pg_hint_plan 1.4 requires PostgreSQL 14.
 417
 418
 419 PostgreSQL versions tested
 420
 421 - Version 14
 422
 423 OS versions tested
 424
 425 - CentOS 8.5
 426
 427 See also
 428 --------
 429
 430 ### PostgreSQL documents
 431
 432 - [EXPLAIN](http://www.postgresql.org/docs/current/static/sql-explain.html)
 433 - [SET](http://www.postgresql.org/docs/current/static/sql-set.html)
 434 - [Server Config](http://www.postgresql.org/docs/current/static/runtime-config.html)
 435 - [Parallel Plans](http://www.postgresql.org/docs/current/static/parallel-plans.html)
 436
 437
 438 ## Hints list
 439
 440 The available hints are listed below.
 441
 442 |             Group            |                                                              Format                                                             |                                                                                                                                                                        Description                                                                                                                                                                       |
 443 |:-----------------------------|:--------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 444 | Scan method                  | `SeqScan(table)`                                                                                                                  | Forces sequential scan on the table                                                                                                                                                                                                                                                                                                                      |
 445 |                              | `TidScan(table)`                                                                                                                  | Forces TID scan on the table.                                                                                                                                                                                                                                                                                                                            |
 446 |                              | `IndexScan(table[ index...])`                                                                                                     | Forces index scan on the table. Restricts to specified indexes if any.                                                                                                                                                                                                                                                                                   |
 447 |                              | `IndexOnlyScan(table[ index...])`                                                                                                 | Forces index only scan on the table. Rstricts to specfied indexes if any. Index scan may be used if index only scan is not available. Available for PostgreSQL 9.2 and later.                                                                                                                                                                            |
 448 |                              | `BitmapScan(table[ index...])`                                                                                                    | Forces bitmap scan on the table. Restoricts to specfied indexes if any.                                                                                                                                                                                                                                                                                  |
 449 |                              | `IndexScanRegexp(table[ POSIX Regexp...])` `IndexOnlyScanRegexp(table[ POSIX Regexp...])` `BitmapScanRegexp(table[ POSIX Regexp...])` | Forces index scan or index only scan (For PostgreSQL 9.2 and later) or bitmap scan on the table. Restricts to indexes that matches the specified POSIX regular expression pattern                                                                                                                                                                        |
 450 |                              | `NoSeqScan(table)`                                                                                                                | Forces not to do sequential scan on the table.                                                                                                                                                                                                                                                                                                           |
 451 |                              | `NoTidScan(table)`                                                                                                                | Forces not to do TID scan on the table.                                                                                                                                                                                                                                                                                                                  |
 452 |                              | `NoIndexScan(table)`                                                                                                              | Forces not to do index scan and index only scan (For PostgreSQL 9.2 and later) on the table.                                                                                                                                                                                                                                                             |
 453 |                              | `NoIndexOnlyScan(table)`                                                                                                          | Forces not to do index only scan on the table. Available for PostgreSQL 9.2 and later.                                                                                                                                                                                                                                                                   |
 454 |                              | `NoBitmapScan(table)`                                                                                                             | Forces not to do bitmap scan on the table.                                                                                                                                                                                                                                                                                                               |
 455 | Join method                  | `NestLoop(table table[ table...])`                                                                                                | Forces nested loop for the joins consist of the specifiled tables.                                                                                                                                                                                                                                                                                       |
 456 |                              | `HashJoin(table table[ table...])`                                                                                                | Forces hash join for the joins consist of the specifiled tables.                                                                                                                                                                                                                                                                                         |
 457 |                              | `MergeJoin(table table[ table...])`                                                                                               | Forces merge join for the joins consist of the specifiled tables.                                                                                                                                                                                                                                                                                        |
 458 |                              | `NoNestLoop(table table[ table...])`                                                                                              | Forces not to do nested loop for the joins consist of the specifiled tables.                                                                                                                                                                                                                                                                             |
 459 |                              | `NoHashJoin(table table[ table...])`                                                                                              | Forces not to do hash join for the joins consist of the specifiled tables.                                                                                                                                                                                                                                                                               |
 460 |                              | `NoMergeJoin(table table[ table...])`                                                                                             | Forces not to do merge join for the joins consist of the specifiled tables.                                                                                                                                                                                                                                                                              |
 461 | Join order                   | `Leading(table table[ table...])`                                                                                                 | Forces join order as specified.                                                                                                                                                                                                                                                                                                                          |
 462 |                              | `Leading(<join pair>)`                                                                                                            | Forces join order and directions as specified. A join pair is a pair of tables and/or other join pairs enclosed by parentheses, which can make a nested structure.                                                                                                                                                                                       |
 463 | Row number correction        | `Rows(table table[ table...] correction)`                                                                                         | Corrects row number of a result of the joins consist of the specfied tables. The available correction methods are absolute (#<n>), addition (+<n>), subtract (-<n>) and multiplication (*<n>). <n> should be a string that strtod() can read.                                                                                                            |
 464 | Parallel query configuration | `Parallel(table <# of workers> [soft\|hard])`                                                                                     | Enforce or inhibit parallel execution of specfied table. <# of workers> is the desired number of parallel workers, where zero means inhibiting parallel execution. If the third parameter is soft (default), it just changes max_parallel_workers_per_gather and leave everything else to planner. Hard means enforcing the specified number of workers. |
 465 | GUC                          | `Set(GUC-param value)`                                                                                                            | Set the GUC parameter to the value while planner is running.                                                                                                                                                                                                                                                                                             |
 466
 467 * * * * *
 468
 469 Copyright (c) 2012-2022, NIPPON TELEGRAPH AND TELEPHONE CORPORATION