Page /Plans
Purpose - Monitoring suspicious queries in different sections.
The lines on the tabs of this page, when clicked, show the composition or template model:
How to go to the page /Plans
Navigate to this page by selecting the number of templates:
Page control panel
The Page Control Panel contains the following elements (as numbered in the figure above):
the mode selection panel;
Templates tab
Purpose - Displays a list of :ref:` <glossary-pg_monitor_шаблон>` templates and their key parameters.
Clicking on a line displays the template model.
Page composition:
"templates"
Number of patterns, to which the problematic problematic queries of the given host can be reduced.
Clicking opens pg_m_Plans.
create a link to the task
Button to create a link to a task (
)Binds this template to an accounting system, tracking errors (for example, jira), pg_monitor will allow you to go to the task specified for this template.
Pressing the button
calls the task link creation window:
"app"
App name.
Clicking on a title sorts the tab by template name.
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"sum.ms"
Total request time in milliseconds.
Clicking on a title sorts the tab by template name.
"avg.ms"
Average request time in milliseconds.
Clicking on a title sorts the tab by template name.
"buf.mem"
Queries whose buffers according to this pattern were considered to be read from memory.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"buf:dsk"
Queries whose buffers according to this template were considered read from disk.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
%
Ratio of disk reads to total (less is better).
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
«By Models» tab
Purpose - Displays a list of <glossary-pg_monitor_модель> query models and their key parameters.
Page composition:
"Model_template"
Template names.
"app"
App name.
Clicking on a title sorts the tab by template name.
"ptr" (pattern)
Displays the number of <pg_m_glossary-pg_monitor_шаблон> templates. When pressed, displays a list of templates. If the pattern is single, the template name is displayed.
Clicking on a title sorts the tab by template name.
Clicking on the template name translates the <pg_m_шаблоны>` «templates» page to :ref:`.
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"sum.ms"
Total request time in milliseconds.
Clicking on a title sorts the tab by template name.
"avg.ms"
Average request time in milliseconds.
Clicking on a title sorts the tab by template name.
"buf.mem"
Queries whose buffers according to this pattern were considered to be read from memory.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"buf:dsk"
Queries whose buffers according to this template were considered read from disk.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
%
Ratio of disk reads to total (less is better).
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Graphical representation of the query model
Tab «by application»
Purpose - grouping problem queries by application (method). Clicking on a row with the selected method reveals its template if it is the only one for that method.
If there are multiple templates, the list of templates is displayed first.
You can then get template displays by clicking on a row from the template list.
Page composition:
"Method_template(s)"
Clicking on a title sorts the tab by template name.
"ptr" (pattern)
Displays the number of <pg_m_glossary-pg_monitor_шаблон> templates. When pressed, displays a list of templates. If the pattern is single, the template name is displayed.
Clicking on a title sorts the tab by template name.
Clicking on the template name translates the <pg_m_шаблоны>` «templates» page to :ref:`.
create a link to the task
Button to create a link to a task (
)Binds this template to an accounting system, tracking errors (for example, jira), pg_monitor will allow you to go to the task specified for this template.
Pressing the button
calls the task link creation window:
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"sum.ms"
Total request time in milliseconds.
Clicking on a title sorts the tab by template name.
"avg.ms"
Average request time in milliseconds.
Clicking on a title sorts the tab by template name.
"buf.mem"
Queries whose buffers according to this pattern were considered to be read from memory.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"buf:dsk"
Queries whose buffers according to this template were considered read from disk.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
%
Ratio of disk reads to total (less is better).
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Base Objects (Operations) tab
Assignment – reviews all instances of plans according to the templates of a given node and tries to select the most appropriate index to each of them, groups this information and builds tracking. Number of entries and number of passes.
Clicking on 
translates to the /node page.
Page composition:
"Node Type"
Clicking on a title sorts the tab by node type.
Clicking on the template name takes you to the :ref:` node page <pg_m_узел>`.
The column displays the main operations displayed in the DBMS query execution plans:
Seq Scan
The operation scans the entire table in the order it is stored on disk. This operation is usually bad for performance because it requires sequential reads to fetch a large number of rows, resulting in slower processing. But there are exceptions, for example, the use of the Limit directive, which limits the number of records returned.
Index Scan
An index scan traverses the index, scans the leaf nodes to find all matching records, and retrieves the matching data from the table. In most cases, this is good for performance because it provides direct access to the required rows of data.
Bitmap Index Scan
While Index Scan retrieves one tuple pointer at a time from the index and immediately jumps to that tuple pointer in the table, Bitmap Index Scan retrieves all tuple pointers from the index at one time, sorts them using the «bitmap» data structure in RAM, and then looks through the tuples of the tables in the order of the physical arrangement of the tuples.
Merge Join
A merge join joins two sorted lists. Both sides of the join must be presorted.
Nested Loops
A nested loop join joins two tables by selecting a result from one table and querying another table for each row from the first. Occurs very often. Performs a fairly efficient join on relatively small datasets. Nested loop join does not require input to be sorted.
Hash Join
A hash join loads the candidate records from one side of the join into a hash table, which is then checked for each row on the other side of the join. The operation is used whenever it is not possible to apply other types of join: if the datasets to be joined are large enough and/or the datasets are not ordered by join columns.
Sort
Sorts the set by the columns specified by the Sort Key. The sort operation requires large amounts of memory to materialize the intermediate result.
Aggregate
Appears in the plan if the query has an aggregate function that is used to calculate individual results from multiple input rows: COUNT, SUM, AVG, MAX, MIN and others.
GroupAggregate
Groups a presorted set according to the GROUP BY clause. This operation does not buffer the intermediate result.
HashAggregate
Uses a temporary hash table to group entries. The HashAggregate operation does not require a pre-sorted data set, instead it uses large amounts of memory to materialize the intermediate result. The output is not ordered in any meaningful way.
Filter
Applies a filter to a set of rows.
Limit
Aborts operations when the desired number of rows has been selected.
Append
Runs multiple sub-operations and returns all the rows they return as a total result. Used in queries containing UNION or UNION ALL.
HashSetOp
The operation is used by the INTERSECT and EXCEPT operations (with the optional ALL modifier). It works like this: it runs Append sub-operations on a couple of subqueries, and then, based on the result and an optional ALL modifier, decides which rows to return.
Materialize
An activity takes data from an underlying activity and places it in memory (or partially in memory) so that it can be used more quickly, or adds additional properties to it that the previous activity does not provide.
CTE Scan
Similar to Materialize. The operation runs a query part and saves its output so that it can be used by another query part(s).
SubPlan
An operation means a subquery that has links to the main query. Called to count data from a subquery that depends on the current row.
InitPlan
An operation means a subquery that has no references to the main query. An operation appears in the plan when there is a part of the query that can (or should) be evaluated first, and it does not depend on anything in the rest of the query.
Subquery Scan
An operation means a subquery included in a UNION.
"table"
Clicking on a heading sorts the tab by that column.
"index"
Clicking on a heading sorts the tab by that column.
"ptr" (pattern)
Displays the number of <pg_m_glossary-pg_monitor_шаблон> templates. When pressed, displays a list of templates. If the pattern is single, the template name is displayed.
Clicking on a title sorts the tab by template name.
Clicking on the template name translates the <pg_m_шаблоны>` «templates» page to :ref:`.
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"loops"
The total number of simple loops for a node like pg_m_glossary-LOOP.
Clicking on a heading sorts the tab by that column.
"loops avg"
Average number of simple loops per node like pg_m_glossary-LOOP.
Clicking on a heading sorts the tab by that column.
"rows_avg"
Average number of lines.
"RRbF"
Rows Removed by Filter
Clicking on a heading sorts the tab by that column.
Displays the statistical information that can be seen in the query execution plan. This value indicates the number of rows that have been deleted since the filter was applied in the scan or join table operation.
When the DBMS executes a query, it applies filters to the data to select only those rows that meet the specified conditions. «Rows Removed by Filter» displays the number of rows that were filtered and deleted after these conditions were applied. This value can be useful to analyze query performance and optimize query execution.
Note that «Rows Removed by Filter» does not indicate the total number of rows selected or returned as a result of the query. RRbF refers only to the number of rows that were deleted after the filter was applied.
RRbF information can be useful in streamlining queries and improving database performance. It can help identify places where indexes or table structure can be improved to reduce the number of rows that do not meet query conditions and are removed by the filter.
"RRbF_avg"
Clicking on a heading sorts the tab by that column.
"RRbF_percent"
Clicking on a heading sorts the tab by that column.
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Base object (resources) tab
The purpose is the amount of data.
Page composition:
"Node Type"
Clicking on a title sorts the tab by node type.
Clicking on the template name takes you to the :ref:` node page <pg_m_узел>`.
The column displays the main operations displayed in the DBMS query execution plans:
Seq Scan
The operation scans the entire table in the order it is stored on disk. This operation is usually bad for performance because it requires sequential reads to fetch a large number of rows, resulting in slower processing. But there are exceptions, for example, the use of the Limit directive, which limits the number of records returned.
Index Scan
An index scan traverses the index, scans the leaf nodes to find all matching records, and retrieves the matching data from the table. In most cases, this is good for performance because it provides direct access to the required rows of data.
Bitmap Index Scan
While Index Scan retrieves one tuple pointer at a time from the index and immediately jumps to that tuple pointer in the table, Bitmap Index Scan retrieves all tuple pointers from the index at one time, sorts them using the «bitmap» data structure in RAM, and then looks through the tuples of the tables in the order of the physical arrangement of the tuples.
Merge Join
A merge join joins two sorted lists. Both sides of the join must be presorted.
Nested Loops
A nested loop join joins two tables by selecting a result from one table and querying another table for each row from the first. Occurs very often. Performs a fairly efficient join on relatively small datasets. Nested loop join does not require input to be sorted.
Hash Join
A hash join loads the candidate records from one side of the join into a hash table, which is then checked for each row on the other side of the join. The operation is used whenever it is not possible to apply other types of join: if the datasets to be joined are large enough and/or the datasets are not ordered by join columns.
Sort
Sorts the set by the columns specified by the Sort Key. The sort operation requires large amounts of memory to materialize the intermediate result.
Aggregate
Appears in the plan if the query has an aggregate function that is used to calculate individual results from multiple input rows: COUNT, SUM, AVG, MAX, MIN and others.
GroupAggregate
Groups a presorted set according to the GROUP BY clause. This operation does not buffer the intermediate result.
HashAggregate
Uses a temporary hash table to group entries. The HashAggregate operation does not require a pre-sorted data set, instead it uses large amounts of memory to materialize the intermediate result. The output is not ordered in any meaningful way.
Filter
Applies a filter to a set of rows.
Limit
Aborts operations when the desired number of rows has been selected.
Append
Runs multiple sub-operations and returns all the rows they return as a total result. Used in queries containing UNION or UNION ALL.
HashSetOp
The operation is used by the INTERSECT and EXCEPT operations (with the optional ALL modifier). It works like this: it runs Append sub-operations on a couple of subqueries, and then, based on the result and an optional ALL modifier, decides which rows to return.
Materialize
An activity takes data from an underlying activity and places it in memory (or partially in memory) so that it can be used more quickly, or adds additional properties to it that the previous activity does not provide.
CTE Scan
Similar to Materialize. The operation runs a query part and saves its output so that it can be used by another query part(s).
SubPlan
An operation means a subquery that has links to the main query. Called to count data from a subquery that depends on the current row.
InitPlan
An operation means a subquery that has no references to the main query. An operation appears in the plan when there is a part of the query that can (or should) be evaluated first, and it does not depend on anything in the rest of the query.
Subquery Scan
An operation means a subquery included in a UNION.
"table"
Clicking on a heading sorts the tab by that column.
"index"
Clicking on a heading sorts the tab by that column.
"ptr" (pattern)
Displays the number of <pg_m_glossary-pg_monitor_шаблон> templates. When pressed, displays a list of templates. If the pattern is single, the template name is displayed.
Clicking on a title sorts the tab by template name.
Clicking on the template name translates the <pg_m_шаблоны>` «templates» page to :ref:`.
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"sum.ms"
Total request time in milliseconds.
Clicking on a title sorts the tab by template name.
"avg.ms"
Average request time in milliseconds.
Clicking on a title sorts the tab by template name.
"buf.mem"
Queries whose buffers according to this pattern were considered to be read from memory.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"buf:dsk"
Queries whose buffers according to this template were considered read from disk.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Dynamic Objects (Operations) tab
Loops, rows.
Page composition:
"Node Type"
Clicking on a title sorts the tab by node type.
Clicking on the template name takes you to the :ref:` node page <pg_m_узел>`.
The column displays the main operations displayed in the DBMS query execution plans:
Seq Scan
The operation scans the entire table in the order it is stored on disk. This operation is usually bad for performance because it requires sequential reads to fetch a large number of rows, resulting in slower processing. But there are exceptions, for example, the use of the Limit directive, which limits the number of records returned.
Index Scan
An index scan traverses the index, scans the leaf nodes to find all matching records, and retrieves the matching data from the table. In most cases, this is good for performance because it provides direct access to the required rows of data.
Bitmap Index Scan
While Index Scan retrieves one tuple pointer at a time from the index and immediately jumps to that tuple pointer in the table, Bitmap Index Scan retrieves all tuple pointers from the index at one time, sorts them using the «bitmap» data structure in RAM, and then looks through the tuples of the tables in the order of the physical arrangement of the tuples.
Merge Join
A merge join joins two sorted lists. Both sides of the join must be presorted.
Nested Loops
A nested loop join joins two tables by selecting a result from one table and querying another table for each row from the first. Occurs very often. Performs a fairly efficient join on relatively small datasets. Nested loop join does not require input to be sorted.
Hash Join
A hash join loads the candidate records from one side of the join into a hash table, which is then checked for each row on the other side of the join. The operation is used whenever it is not possible to apply other types of join: if the datasets to be joined are large enough and/or the datasets are not ordered by join columns.
Sort
Sorts the set by the columns specified by the Sort Key. The sort operation requires large amounts of memory to materialize the intermediate result.
Aggregate
Appears in the plan if the query has an aggregate function that is used to calculate individual results from multiple input rows: COUNT, SUM, AVG, MAX, MIN and others.
GroupAggregate
Groups a presorted set according to the GROUP BY clause. This operation does not buffer the intermediate result.
HashAggregate
Uses a temporary hash table to group entries. The HashAggregate operation does not require a pre-sorted data set, instead it uses large amounts of memory to materialize the intermediate result. The output is not ordered in any meaningful way.
Filter
Applies a filter to a set of rows.
Limit
Aborts operations when the desired number of rows has been selected.
Append
Runs multiple sub-operations and returns all the rows they return as a total result. Used in queries containing UNION or UNION ALL.
HashSetOp
The operation is used by the INTERSECT and EXCEPT operations (with the optional ALL modifier). It works like this: it runs Append sub-operations on a couple of subqueries, and then, based on the result and an optional ALL modifier, decides which rows to return.
Materialize
An activity takes data from an underlying activity and places it in memory (or partially in memory) so that it can be used more quickly, or adds additional properties to it that the previous activity does not provide.
CTE Scan
Similar to Materialize. The operation runs a query part and saves its output so that it can be used by another query part(s).
SubPlan
An operation means a subquery that has links to the main query. Called to count data from a subquery that depends on the current row.
InitPlan
An operation means a subquery that has no references to the main query. An operation appears in the plan when there is a part of the query that can (or should) be evaluated first, and it does not depend on anything in the rest of the query.
Subquery Scan
An operation means a subquery included in a UNION.
"table"
Clicking on a heading sorts the tab by that column.
"ptr" (pattern)
Displays the number of <pg_m_glossary-pg_monitor_шаблон> templates. When pressed, displays a list of templates. If the pattern is single, the template name is displayed.
Clicking on a title sorts the tab by template name.
Clicking on the template name translates the <pg_m_шаблоны>` «templates» page to :ref:`.
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"loops"
The total number of simple loops for a node like pg_m_glossary-LOOP.
Clicking on a heading sorts the tab by that column.
"loops avg"
Average number of simple loops per node like pg_m_glossary-LOOP.
Clicking on a heading sorts the tab by that column.
"rows_avg"
Average number of lines.
"RRbF"
Rows Removed by Filter
Clicking on a heading sorts the tab by that column.
Displays the statistical information that can be seen in the query execution plan. This value indicates the number of rows that have been deleted since the filter was applied in the scan or join table operation.
When the DBMS executes a query, it applies filters to the data to select only those rows that meet the specified conditions. «Rows Removed by Filter» displays the number of rows that were filtered and deleted after these conditions were applied. This value can be useful to analyze query performance and optimize query execution.
Note that «Rows Removed by Filter» does not indicate the total number of rows selected or returned as a result of the query. RRbF refers only to the number of rows that were deleted after the filter was applied.
RRbF information can be useful in streamlining queries and improving database performance. It can help identify places where indexes or table structure can be improved to reduce the number of rows that do not meet query conditions and are removed by the filter.
"RRbF_avg"
Clicking on a heading sorts the tab by that column.
"RRbF_percent"
Clicking on a heading sorts the tab by that column.
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Dynamic Objects (Resources) tab
Buffers, time.
Page composition:
"Node Type"
Clicking on a title sorts the tab by node type.
Clicking on the template name takes you to the :ref:` node page <pg_m_узел>`.
The column displays the main operations displayed in the DBMS query execution plans:
Seq Scan
The operation scans the entire table in the order it is stored on disk. This operation is usually bad for performance because it requires sequential reads to fetch a large number of rows, resulting in slower processing. But there are exceptions, for example, the use of the Limit directive, which limits the number of records returned.
Index Scan
An index scan traverses the index, scans the leaf nodes to find all matching records, and retrieves the matching data from the table. In most cases, this is good for performance because it provides direct access to the required rows of data.
Bitmap Index Scan
While Index Scan retrieves one tuple pointer at a time from the index and immediately jumps to that tuple pointer in the table, Bitmap Index Scan retrieves all tuple pointers from the index at one time, sorts them using the «bitmap» data structure in RAM, and then looks through the tuples of the tables in the order of the physical arrangement of the tuples.
Merge Join
A merge join joins two sorted lists. Both sides of the join must be presorted.
Nested Loops
A nested loop join joins two tables by selecting a result from one table and querying another table for each row from the first. Occurs very often. Performs a fairly efficient join on relatively small datasets. Nested loop join does not require input to be sorted.
Hash Join
A hash join loads the candidate records from one side of the join into a hash table, which is then checked for each row on the other side of the join. The operation is used whenever it is not possible to apply other types of join: if the datasets to be joined are large enough and/or the datasets are not ordered by join columns.
Sort
Sorts the set by the columns specified by the Sort Key. The sort operation requires large amounts of memory to materialize the intermediate result.
Aggregate
Appears in the plan if the query has an aggregate function that is used to calculate individual results from multiple input rows: COUNT, SUM, AVG, MAX, MIN and others.
GroupAggregate
Groups a presorted set according to the GROUP BY clause. This operation does not buffer the intermediate result.
HashAggregate
Uses a temporary hash table to group entries. The HashAggregate operation does not require a pre-sorted data set, instead it uses large amounts of memory to materialize the intermediate result. The output is not ordered in any meaningful way.
Filter
Applies a filter to a set of rows.
Limit
Aborts operations when the desired number of rows has been selected.
Append
Runs multiple sub-operations and returns all the rows they return as a total result. Used in queries containing UNION or UNION ALL.
HashSetOp
The operation is used by the INTERSECT and EXCEPT operations (with the optional ALL modifier). It works like this: it runs Append sub-operations on a couple of subqueries, and then, based on the result and an optional ALL modifier, decides which rows to return.
Materialize
An activity takes data from an underlying activity and places it in memory (or partially in memory) so that it can be used more quickly, or adds additional properties to it that the previous activity does not provide.
CTE Scan
Similar to Materialize. The operation runs a query part and saves its output so that it can be used by another query part(s).
SubPlan
An operation means a subquery that has links to the main query. Called to count data from a subquery that depends on the current row.
InitPlan
An operation means a subquery that has no references to the main query. An operation appears in the plan when there is a part of the query that can (or should) be evaluated first, and it does not depend on anything in the rest of the query.
Subquery Scan
An operation means a subquery included in a UNION.
"table"
Clicking on a heading sorts the tab by that column.
"index"
Clicking on a heading sorts the tab by that column.
"ptr" (pattern)
Displays the number of <pg_m_glossary-pg_monitor_шаблон> templates. When pressed, displays a list of templates. If the pattern is single, the template name is displayed.
Clicking on a title sorts the tab by template name.
Clicking on the template name translates the <pg_m_шаблоны>` «templates» page to :ref:`.
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"sum.ms"
Total request time in milliseconds.
Clicking on a title sorts the tab by template name.
"avg.ms"
Average request time in milliseconds.
Clicking on a title sorts the tab by template name.
"buf.mem"
Queries whose buffers according to this pattern were considered to be read from memory.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"buf:dsk"
Queries whose buffers according to this template were considered read from disk.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Tab «by trigger»
Page composition:
"Node Type"
Clicking on a title sorts the tab by node type.
Clicking on the template name takes you to the :ref:` node page <pg_m_узел>`.
The column displays the main operations displayed in the DBMS query execution plans:
Seq Scan
The operation scans the entire table in the order it is stored on disk. This operation is usually bad for performance because it requires sequential reads to fetch a large number of rows, resulting in slower processing. But there are exceptions, for example, the use of the Limit directive, which limits the number of records returned.
Index Scan
An index scan traverses the index, scans the leaf nodes to find all matching records, and retrieves the matching data from the table. In most cases, this is good for performance because it provides direct access to the required rows of data.
Bitmap Index Scan
While Index Scan retrieves one tuple pointer at a time from the index and immediately jumps to that tuple pointer in the table, Bitmap Index Scan retrieves all tuple pointers from the index at one time, sorts them using the «bitmap» data structure in RAM, and then looks through the tuples of the tables in the order of the physical arrangement of the tuples.
Merge Join
A merge join joins two sorted lists. Both sides of the join must be presorted.
Nested Loops
A nested loop join joins two tables by selecting a result from one table and querying another table for each row from the first. Occurs very often. Performs a fairly efficient join on relatively small datasets. Nested loop join does not require input to be sorted.
Hash Join
A hash join loads the candidate records from one side of the join into a hash table, which is then checked for each row on the other side of the join. The operation is used whenever it is not possible to apply other types of join: if the datasets to be joined are large enough and/or the datasets are not ordered by join columns.
Sort
Sorts the set by the columns specified by the Sort Key. The sort operation requires large amounts of memory to materialize the intermediate result.
Aggregate
Appears in the plan if the query has an aggregate function that is used to calculate individual results from multiple input rows: COUNT, SUM, AVG, MAX, MIN and others.
GroupAggregate
Groups a presorted set according to the GROUP BY clause. This operation does not buffer the intermediate result.
HashAggregate
Uses a temporary hash table to group entries. The HashAggregate operation does not require a pre-sorted data set, instead it uses large amounts of memory to materialize the intermediate result. The output is not ordered in any meaningful way.
Filter
Applies a filter to a set of rows.
Limit
Aborts operations when the desired number of rows has been selected.
Append
Runs multiple sub-operations and returns all the rows they return as a total result. Used in queries containing UNION or UNION ALL.
HashSetOp
The operation is used by the INTERSECT and EXCEPT operations (with the optional ALL modifier). It works like this: it runs Append sub-operations on a couple of subqueries, and then, based on the result and an optional ALL modifier, decides which rows to return.
Materialize
An activity takes data from an underlying activity and places it in memory (or partially in memory) so that it can be used more quickly, or adds additional properties to it that the previous activity does not provide.
CTE Scan
Similar to Materialize. The operation runs a query part and saves its output so that it can be used by another query part(s).
SubPlan
An operation means a subquery that has links to the main query. Called to count data from a subquery that depends on the current row.
InitPlan
An operation means a subquery that has no references to the main query. An operation appears in the plan when there is a part of the query that can (or should) be evaluated first, and it does not depend on anything in the rest of the query.
Subquery Scan
An operation means a subquery included in a UNION.
"table"
Clicking on a heading sorts the tab by that column.
"ptr" (pattern)
Displays the number of <pg_m_glossary-pg_monitor_шаблон> templates. When pressed, displays a list of templates. If the pattern is single, the template name is displayed.
Clicking on a title sorts the tab by template name.
Clicking on the template name translates the <pg_m_шаблоны>` «templates» page to :ref:`.
"count"
Quantity.
Clicking on a title sorts the tab by template name.
"calls"
«CALL» is used to call stored procedures or functions. Stored procedures and functions are a set of SQL statements grouped together under a specific name and usually perform some kind of operation on a database.
To call a stored procedure or function, you can use the following syntax:
CALL procedure_name(argument1, argument2, ...)
or
CALL my_procedure('argument_value')
An example of calling a stored function with no arguments and assigning the result to a variable:
SELECT * INTO result_variable FROM my_function()
"calls.avg"
Average number of calls.
"sum.ms"
Total request time in milliseconds.
Clicking on a title sorts the tab by template name.
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Peak Chains tab
Purpose – display a set of plan execution facts according to the same template that are chained in time. The key feature of this tab is the chain data in relation to the corresponding templates and methods.
Clicking a row on a template reveals information about the order in which operations are performed and the links between the various nodes in the execution plan (<pg_m_glossary-pg_monitor_шаблон> query template) and a list of methods according to the number in the «chains» box.
Page composition:
"Template/method"
Contains the <pg_m_glossary-pg_monitor_шаблон> pattern“ and the query method.
Clicking on a title sorts the tab by template name.
Clicking on the template title translates to the page of the template.
create a link to the task
Button to create a link to a task (
)Binds this template to an accounting system, tracking errors (for example, jira), pg_monitor will allow you to go to the task specified for this template.
Pressing the button
calls the task link creation window:
"событий"
Соличество событий данного шаблона.
"strings"
Chains - a set of facts about the execution of plans according to the same template, which are linked in time.
In chained queries, the results of one subquery or node are used as input to the next subquery or node. For example, sort results from one node can be passed to the next node for window functions or further processing. This allows you to optimize query execution and reduce the need for intermediate storage and loading of data.
"length_max"
Maximum length of chain.
"avg_length"
Average length of string.
"avg.ms"
Average request time in milliseconds.
Clicking on a title sorts the tab by template name.
"last"
The time of the last request.
Clicking on a title sorts the tab by template name.
Clicking on a value takes you to the request page from the archive.
"Timeline"
A graph showing the intensity of problem Queries, broken down into 24 hours.
Time and Resources tab
The purpose is to match methods in query composition to the resources they consume.
Page composition:
"Method"
Method used in plan to perform a specific operation
"pattern"
A template is a representation of a query, a query plan de-numbed, its structure.
"counter"
Request Counter.
indicates that this is the first time the plan has appeared in this list."time, ms"
Time in milliseconds.
"buffers"
Cumulative amount of buffered memory.
"buf.mem"
Queries whose buffers according to this pattern were considered to be read from memory.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
"buf:dsk"
Queries whose buffers according to this template were considered read from disk.
Clicking on a title sorts the tab by template name.
Hovering over the value will display the tultype with the volume value.
%
Ratio of disk reads to total (less is better).
"time"
Time to register the request.
When pressed, translates the query page from the <pg_m_Архив_запрос>` archive to :ref:`.
