{"kind": "plan", "major": "18", "item": {"slug": "unique", "name": "Unique", "name_zh": "Unique", "category": "Combination", "summary": "Removes adjacent duplicates from a sorted input stream.", "aliases": ["T_Unique", "Unique"], "content_hash": "7b7c186b69e0bddde136ba6b8aa1564bae380a0e2032974bc974f63554d59982", "versions": {"10": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v10.23/postgresql-10.23.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "cc2a6aa9776678b5d1b5d1d8b5796b394b7a4a2b693c011c398032151da0e31e", "archive_sha256": "94a4b2528372458e5662c18d406629266667c437198160a18cdfd2c4a4d6eee9"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=10", "label": "EXPLAIN"}, {"url": "/docs/10/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/10/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 10.23 source archive", "label": "10.23", "major": "10", "channel": "historical", "revision": "94a4b2528372458e5662c18d406629266667c437198160a18cdfd2c4a4d6eee9", "source_url": "https://ftp.postgresql.org/pub/source/v10.23/postgresql-10.23.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v10.23/postgresql-10.23.tar.bz2", "line": 1068, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1068", "sha256": "a785298532047cfeda969e78c3597a343dc1c56d61ba85830b0f16a02a14b5a1", "archive_sha256": "94a4b2528372458e5662c18d406629266667c437198160a18cdfd2c4a4d6eee9"}, {"url": "https://ftp.postgresql.org/pub/source/v10.23/postgresql-10.23.tar.bz2", "line": 333, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:333", "sha256": "cea76648bb38ae55f18f989768bee1a4ee025691ceea0f86bccb29dcdc166acc", "archive_sha256": "94a4b2528372458e5662c18d406629266667c437198160a18cdfd2c4a4d6eee9"}, {"url": "https://ftp.postgresql.org/pub/source/v10.23/postgresql-10.23.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "cc2a6aa9776678b5d1b5d1d8b5796b394b7a4a2b693c011c398032151da0e31e", "archive_sha256": "94a4b2528372458e5662c18d406629266667c437198160a18cdfd2c4a4d6eee9"}, {"url": "https://ftp.postgresql.org/pub/source/v10.23/postgresql-10.23.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "d562c321108844798cd234303fffb618f13d4ee3f3a5ac79bfd963b077e47c22", "archive_sha256": "94a4b2528372458e5662c18d406629266667c437198160a18cdfd2c4a4d6eee9"}, {"url": "/docs/10/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 10.23 \u00b7 using-explain", "sha256": "a4b4304aedb0a2da0145cc7c35b03b319a5c7ee3df35a8ef84ab6d3a610f98f3"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. Notice that the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved by the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.91, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..483.00 rows=7001 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/10/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 10.23 \u00b7 using-explain", "sha256": "a4b4304aedb0a2da0145cc7c35b03b319a5c7ee3df35a8ef84ab6d3a610f98f3"}, "paragraphs": ["Example copied from the PostgreSQL 10.23 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/10/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 10.23 \u00b7 using-explain", "sha256": "a4b4304aedb0a2da0145cc7c35b03b319a5c7ee3df35a8ef84ab6d3a610f98f3"}, "paragraphs": ["Example copied from the PostgreSQL 10.23 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "11": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v11.22/postgresql-11.22.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "010f15949eb4d6ca8312f62b4e0e1143bee8e79d51bd1f7737b8bf0923ca9255", "archive_sha256": "2cb7c97d7a0d7278851bbc9c61f467b69c094c72b81740b751108e7892ebe1f0"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=11", "label": "EXPLAIN"}, {"url": "/docs/11/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/11/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 11.22 source archive", "label": "11.22", "major": "11", "channel": "historical", "revision": "2cb7c97d7a0d7278851bbc9c61f467b69c094c72b81740b751108e7892ebe1f0", "source_url": "https://ftp.postgresql.org/pub/source/v11.22/postgresql-11.22.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v11.22/postgresql-11.22.tar.bz2", "line": 1193, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1193", "sha256": "9df8400c1a4377179572ceb916d6020fca4e2760f74bf416d77ed97476523bbd", "archive_sha256": "2cb7c97d7a0d7278851bbc9c61f467b69c094c72b81740b751108e7892ebe1f0"}, {"url": "https://ftp.postgresql.org/pub/source/v11.22/postgresql-11.22.tar.bz2", "line": 333, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:333", "sha256": "95ef4d4a5df4c29f14af9763fae2c530449bdacdf3853d9ff297adf1fed6153b", "archive_sha256": "2cb7c97d7a0d7278851bbc9c61f467b69c094c72b81740b751108e7892ebe1f0"}, {"url": "https://ftp.postgresql.org/pub/source/v11.22/postgresql-11.22.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "010f15949eb4d6ca8312f62b4e0e1143bee8e79d51bd1f7737b8bf0923ca9255", "archive_sha256": "2cb7c97d7a0d7278851bbc9c61f467b69c094c72b81740b751108e7892ebe1f0"}, {"url": "https://ftp.postgresql.org/pub/source/v11.22/postgresql-11.22.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "5e0511194183800e8d6eb293fd4b40639c7d3118e2d199c8e7865ba4fa4cf67f", "archive_sha256": "2cb7c97d7a0d7278851bbc9c61f467b69c094c72b81740b751108e7892ebe1f0"}, {"url": "/docs/11/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 11.22 \u00b7 using-explain", "sha256": "8411bc78085d4737e32d7cca103d859da6c6539e33ec5e2fba46e74c6f199d8a"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. Notice that the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved by the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.91, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..483.00 rows=7001 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/11/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 11.22 \u00b7 using-explain", "sha256": "8411bc78085d4737e32d7cca103d859da6c6539e33ec5e2fba46e74c6f199d8a"}, "paragraphs": ["Example copied from the PostgreSQL 11.22 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/11/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 11.22 \u00b7 using-explain", "sha256": "8411bc78085d4737e32d7cca103d859da6c6539e33ec5e2fba46e74c6f199d8a"}, "paragraphs": ["Example copied from the PostgreSQL 11.22 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "12": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v12.22/postgresql-12.22.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "94195158301d22017aea78199e610acc8902e07a2b1a0614116e6e9399939741", "archive_sha256": "8df3c0474782589d3c6f374b5133b1bd14d168086edbc13c6e72e67dd4527a3b"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=12", "label": "EXPLAIN"}, {"url": "/docs/12/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/12/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 12.22 source archive", "label": "12.22", "major": "12", "channel": "historical", "revision": "8df3c0474782589d3c6f374b5133b1bd14d168086edbc13c6e72e67dd4527a3b", "source_url": "https://ftp.postgresql.org/pub/source/v12.22/postgresql-12.22.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v12.22/postgresql-12.22.tar.bz2", "line": 1264, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1264", "sha256": "d02ea84fdaa201de5d9360645a9f24bfbd2c31f7d45a639e09560ac0e6b6471d", "archive_sha256": "8df3c0474782589d3c6f374b5133b1bd14d168086edbc13c6e72e67dd4527a3b"}, {"url": "https://ftp.postgresql.org/pub/source/v12.22/postgresql-12.22.tar.bz2", "line": 333, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:333", "sha256": "311b17379fe54e3f342fe5ad41c43afbdfa1b844978db2bb2eb22b82520d3256", "archive_sha256": "8df3c0474782589d3c6f374b5133b1bd14d168086edbc13c6e72e67dd4527a3b"}, {"url": "https://ftp.postgresql.org/pub/source/v12.22/postgresql-12.22.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "94195158301d22017aea78199e610acc8902e07a2b1a0614116e6e9399939741", "archive_sha256": "8df3c0474782589d3c6f374b5133b1bd14d168086edbc13c6e72e67dd4527a3b"}, {"url": "https://ftp.postgresql.org/pub/source/v12.22/postgresql-12.22.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "b0c4a0aeb48660ce06e5e700d5529ca9066fd16682bd15783d6e71b5420b07b0", "archive_sha256": "8df3c0474782589d3c6f374b5133b1bd14d168086edbc13c6e72e67dd4527a3b"}, {"url": "/docs/12/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 12.22 \u00b7 using-explain", "sha256": "06297525f2180b07e752837a3351be9c871b56559f535bcd0a67dec9baac10c0"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. Notice that the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved by the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.91, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..483.00 rows=7001 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/12/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 12.22 \u00b7 using-explain", "sha256": "06297525f2180b07e752837a3351be9c871b56559f535bcd0a67dec9baac10c0"}, "paragraphs": ["Example copied from the PostgreSQL 12.22 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/12/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 12.22 \u00b7 using-explain", "sha256": "06297525f2180b07e752837a3351be9c871b56559f535bcd0a67dec9baac10c0"}, "paragraphs": ["Example copied from the PostgreSQL 12.22 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "13": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v13.23/postgresql-13.23.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "3a9e0c3c2b2d1a6e347e08fc29d1da827d1547cc3ee4af9e0dd80c5768b35281", "archive_sha256": "6ec3c82726af92b7dec873fa1cdf881eca92a4219787dfad05acb6b10e041fd6"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=13", "label": "EXPLAIN"}, {"url": "/docs/13/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/13/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 13.23 source archive", "label": "13.23", "major": "13", "channel": "historical", "revision": "6ec3c82726af92b7dec873fa1cdf881eca92a4219787dfad05acb6b10e041fd6", "source_url": "https://ftp.postgresql.org/pub/source/v13.23/postgresql-13.23.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v13.23/postgresql-13.23.tar.bz2", "line": 1325, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1325", "sha256": "541713e0e7f1c9cc352c2b6028964d440c19d2678a4463000094c24a88c1e730", "archive_sha256": "6ec3c82726af92b7dec873fa1cdf881eca92a4219787dfad05acb6b10e041fd6"}, {"url": "https://ftp.postgresql.org/pub/source/v13.23/postgresql-13.23.tar.bz2", "line": 338, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:338", "sha256": "d085ee99acfa00587e6ade3a1d9f8108a0566beedbbee3f54a50c9fc0cc2e875", "archive_sha256": "6ec3c82726af92b7dec873fa1cdf881eca92a4219787dfad05acb6b10e041fd6"}, {"url": "https://ftp.postgresql.org/pub/source/v13.23/postgresql-13.23.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "3a9e0c3c2b2d1a6e347e08fc29d1da827d1547cc3ee4af9e0dd80c5768b35281", "archive_sha256": "6ec3c82726af92b7dec873fa1cdf881eca92a4219787dfad05acb6b10e041fd6"}, {"url": "https://ftp.postgresql.org/pub/source/v13.23/postgresql-13.23.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "dcb296833777b02008c4b6bae8e8f7c6423b7ffba21f36702597c9d596d039ab", "archive_sha256": "6ec3c82726af92b7dec873fa1cdf881eca92a4219787dfad05acb6b10e041fd6"}, {"url": "/docs/13/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 13.23 \u00b7 using-explain", "sha256": "650fd8629382d5dc8f9f8412c50ec5f32442a9ad2f98ca88e5348a7c2bd0ac7a"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. Notice that the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved by the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.91, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..483.00 rows=7001 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/13/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 13.23 \u00b7 using-explain", "sha256": "650fd8629382d5dc8f9f8412c50ec5f32442a9ad2f98ca88e5348a7c2bd0ac7a"}, "paragraphs": ["Example copied from the PostgreSQL 13.23 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/13/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 13.23 \u00b7 using-explain", "sha256": "650fd8629382d5dc8f9f8412c50ec5f32442a9ad2f98ca88e5348a7c2bd0ac7a"}, "paragraphs": ["Example copied from the PostgreSQL 13.23 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "14": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v14.24/postgresql-14.24.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "75ad8cd26bf8691b2386e55fd2b6b42dd0375f94ff15d7eedb27a5466753932e", "archive_sha256": "a7fa7ed3d558172355f51406097a7bd4f6b473be80f311ef7cda96bf383d8897"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=14", "label": "EXPLAIN"}, {"url": "/docs/14/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/14/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 14.24 source archive", "label": "14.24", "major": "14", "channel": "stable", "revision": "a7fa7ed3d558172355f51406097a7bd4f6b473be80f311ef7cda96bf383d8897", "source_url": "https://ftp.postgresql.org/pub/source/v14.24/postgresql-14.24.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v14.24/postgresql-14.24.tar.bz2", "line": 1367, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1367", "sha256": "e091be4e2a083b8dea39ccd09beedede22c1716ef974da66c214a44f48be8c41", "archive_sha256": "a7fa7ed3d558172355f51406097a7bd4f6b473be80f311ef7cda96bf383d8897"}, {"url": "https://ftp.postgresql.org/pub/source/v14.24/postgresql-14.24.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "72da1c5ad457f1d92a39ab73531701794df858419e3b89d6e6cb7079634e68fa", "archive_sha256": "a7fa7ed3d558172355f51406097a7bd4f6b473be80f311ef7cda96bf383d8897"}, {"url": "https://ftp.postgresql.org/pub/source/v14.24/postgresql-14.24.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "75ad8cd26bf8691b2386e55fd2b6b42dd0375f94ff15d7eedb27a5466753932e", "archive_sha256": "a7fa7ed3d558172355f51406097a7bd4f6b473be80f311ef7cda96bf383d8897"}, {"url": "https://ftp.postgresql.org/pub/source/v14.24/postgresql-14.24.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "302f51a16b570dba7ec4e7bc045f7df5800d21630280354d1a24025f3baec75d", "archive_sha256": "a7fa7ed3d558172355f51406097a7bd4f6b473be80f311ef7cda96bf383d8897"}, {"url": "/docs/14/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 14.24 \u00b7 using-explain", "sha256": "7f5ab59cb21a035ada45ea3426c5d1cca3f781273483677f73fdd76753555206"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. Notice that the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved by the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.91, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..483.00 rows=7001 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/14/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 14.24 \u00b7 using-explain", "sha256": "7f5ab59cb21a035ada45ea3426c5d1cca3f781273483677f73fdd76753555206"}, "paragraphs": ["Example copied from the PostgreSQL 14.24 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/14/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 14.24 \u00b7 using-explain", "sha256": "7f5ab59cb21a035ada45ea3426c5d1cca3f781273483677f73fdd76753555206"}, "paragraphs": ["Example copied from the PostgreSQL 14.24 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "15": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v15.19/postgresql-15.19.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "ab3fd8920baba0cf0e0001b8130c31cc018d76515cdb0438c0e4614c261dcb67", "archive_sha256": "e1a64a87a46b825b88c082e4518161a47aab53c45694964f8ba1df28f7859f89"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=15", "label": "EXPLAIN"}, {"url": "/docs/15/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/15/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 15.19 source archive", "label": "15.19", "major": "15", "channel": "stable", "revision": "e1a64a87a46b825b88c082e4518161a47aab53c45694964f8ba1df28f7859f89", "source_url": "https://ftp.postgresql.org/pub/source/v15.19/postgresql-15.19.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v15.19/postgresql-15.19.tar.bz2", "line": 1370, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1370", "sha256": "bb3b442d0f1b098aa8707335250102f027a596cd94117308bd16d1d36b258f5c", "archive_sha256": "e1a64a87a46b825b88c082e4518161a47aab53c45694964f8ba1df28f7859f89"}, {"url": "https://ftp.postgresql.org/pub/source/v15.19/postgresql-15.19.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "19836c50a272741a4eac653541e655437c2e00710a541e5348d6a277d0669d7c", "archive_sha256": "e1a64a87a46b825b88c082e4518161a47aab53c45694964f8ba1df28f7859f89"}, {"url": "https://ftp.postgresql.org/pub/source/v15.19/postgresql-15.19.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "ab3fd8920baba0cf0e0001b8130c31cc018d76515cdb0438c0e4614c261dcb67", "archive_sha256": "e1a64a87a46b825b88c082e4518161a47aab53c45694964f8ba1df28f7859f89"}, {"url": "https://ftp.postgresql.org/pub/source/v15.19/postgresql-15.19.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "fb4a4c8165495299131173680bc02a950d88e1ff610231fd97997bc0c9afc1d7", "archive_sha256": "e1a64a87a46b825b88c082e4518161a47aab53c45694964f8ba1df28f7859f89"}, {"url": "/docs/15/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 15.19 \u00b7 using-explain", "sha256": "d1f509457c647da453d2575c772d91022a0f115dd84f9a3b20f5ff25a243648f"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. Notice that the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved by the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.91, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..483.00 rows=7001 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/15/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 15.19 \u00b7 using-explain", "sha256": "d1f509457c647da453d2575c772d91022a0f115dd84f9a3b20f5ff25a243648f"}, "paragraphs": ["Example copied from the PostgreSQL 15.19 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/15/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 15.19 \u00b7 using-explain", "sha256": "d1f509457c647da453d2575c772d91022a0f115dd84f9a3b20f5ff25a243648f"}, "paragraphs": ["Example copied from the PostgreSQL 15.19 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "16": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "7cc2646be4fd7bb8d069a0894601fad6a8aee5cfe5ab46238000dbfabf94135d", "archive_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=16", "label": "EXPLAIN"}, {"url": "/docs/16/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/16/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 16.15 source archive", "label": "16.15", "major": "16", "channel": "stable", "revision": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed", "source_url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "line": 1403, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1403", "sha256": "8e017f0116dbea471339b40c37a667cc9f95039e7e0329c783e5e8ce194de7e1", "archive_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}, {"url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "e48c08e555f8cb4e4bb43df516c4b8906ce9bc374b2a745d98a1fc8c22cc5099", "archive_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}, {"url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "7cc2646be4fd7bb8d069a0894601fad6a8aee5cfe5ab46238000dbfabf94135d", "archive_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}, {"url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "97db47353db76326b874589a5ad0a04501cc74cd72e237e7bd956e7472c41f1f", "archive_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}, {"url": "/docs/16/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 16.15 \u00b7 using-explain", "sha256": "bd8b86e5281cf0e52ad6e0e4bb8b6ff6510dac61982b44f0c1dd07d54012db3c"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. Notice that the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved by the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.91, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..483.00 rows=7001 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/16/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 16.15 \u00b7 using-explain", "sha256": "bd8b86e5281cf0e52ad6e0e4bb8b6ff6510dac61982b44f0c1dd07d54012db3c"}, "paragraphs": ["Example copied from the PostgreSQL 16.15 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/16/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 16.15 \u00b7 using-explain", "sha256": "bd8b86e5281cf0e52ad6e0e4bb8b6ff6510dac61982b44f0c1dd07d54012db3c"}, "paragraphs": ["Example copied from the PostgreSQL 16.15 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "17": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "630691eaa5099f8536a581ce0c7e564a82b96cb3fc13159db5bf8930cf354c13", "archive_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=17", "label": "EXPLAIN"}, {"url": "/docs/17/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/17/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 17.11 source archive", "label": "17.11", "major": "17", "channel": "stable", "revision": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979", "source_url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "line": 1592, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1592", "sha256": "741251b1a3b6d269a52a673d42eb63b02e13a5872db7b359b137086ab21b63c8", "archive_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, {"url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "a77576e158b94cb01fa8c5174ba133004eabdd727660323f8afc66c8d2e757b8", "archive_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, {"url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "630691eaa5099f8536a581ce0c7e564a82b96cb3fc13159db5bf8930cf354c13", "archive_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, {"url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "d390dd69e2d3f5085beb42b33e46ff0676a2959b916a12b82118a7e545f8e562", "archive_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, {"url": "/docs/17/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 17.11 \u00b7 using-explain", "sha256": "8e3422c77496cc53bfc225ccadda3e82eb23c8c362b8eb95e7fb02cdb315ea78"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. That's because the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved using the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.90, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..470.00 rows=7000 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/17/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 17.11 \u00b7 using-explain", "sha256": "8e3422c77496cc53bfc225ccadda3e82eb23c8c362b8eb95e7fb02cdb315ea78"}, "paragraphs": ["Example copied from the PostgreSQL 17.11 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/17/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 17.11 \u00b7 using-explain", "sha256": "8e3422c77496cc53bfc225ccadda3e82eb23c8c362b8eb95e7fb02cdb315ea78"}, "paragraphs": ["Example copied from the PostgreSQL 17.11 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "18": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "462de2b51c7c7501d5a83d1b5e4435ef9e752c1f1d1934c428f2d8577bd43e45", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=18", "label": "EXPLAIN"}, {"url": "/docs/18/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/18/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 18.6 source archive", "label": "18.6", "major": "18", "channel": "stable", "revision": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f", "source_url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "line": 1577, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1577", "sha256": "34c86d6070224a0e981efef51f79101d6d505e5874f1684ace183034bab14bb4", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "f8a06a3f539077249b20664b2812433db6d7bd12b2c0ca633525db43d06f112a", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "462de2b51c7c7501d5a83d1b5e4435ef9e752c1f1d1934c428f2d8577bd43e45", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "52422b327a8049fbbb20d8b96008a0fc0a6fafa60f7eff3c695d5b2e83830120", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "/docs/18/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}, {"url": "/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. That's because the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved using the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.90, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan.", "Here we see an Index-Only Scan node using tenk1_four_unique1_idx , a multi-column index on the tenk1 table's four and unique1 columns. The scan performs 3 searches that each read a single index leaf page: \u201c four = 1 AND unique1 = 42 \u201d , \u201c four = 2 AND unique1 = 42 \u201d , and \u201c four = 3 AND unique1 = 42 \u201d . This index is generally a good target for skip scan, since, as discussed in Section 11.3 , its leading column (the four column) contains only 4 distinct values, while its second/final column (the unique1 column) contains many distinct values."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..470.00 rows=7000 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/18/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}, "paragraphs": ["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/18/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}, "paragraphs": ["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "19": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "cba8bdfb7ca2a921f05c74fe0598cbac4e7b0dac0ee4b7f2095fe49d870e60bd", "archive_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=19", "label": "EXPLAIN"}, {"url": "/docs/19/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/19/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 19beta4 source archive", "label": "19beta4", "major": "19", "channel": "preview", "revision": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86", "source_url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "line": 1589, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1589", "sha256": "8b115b1c194a4b54ae630209a741e293b1df49a9052f10b2de9ca092a48998e3", "archive_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, {"url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "5e39b2037bed672da55104229ecc32da5abde44c26bcad01479edcfa044d09ed", "archive_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, {"url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "cba8bdfb7ca2a921f05c74fe0598cbac4e7b0dac0ee4b7f2095fe49d870e60bd", "archive_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, {"url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "1c65d5d6b6c81c71531685843647869bcae630779d815a5036b06e070c6c06c7", "archive_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, {"url": "/docs/19/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 19beta4 \u00b7 using-explain", "sha256": "52f111fbd213e2200146319d01a9dcc2ea90001617d2a28edc52f7954c2dd70b"}, {"url": "/docs/19/using-explain.html#USING-EXPLAIN-ANALYZE", "path": "using-explain.html", "label": "PostgreSQL 19beta4 \u00b7 using-explain", "sha256": "52f111fbd213e2200146319d01a9dcc2ea90001617d2a28edc52f7954c2dd70b"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. That's because the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved using the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.90, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan.", "Here we see an Index-Only Scan node using tenk1_four_unique1_idx , a multi-column index on the tenk1 table's four and unique1 columns. The scan performs 3 searches that each read a single index leaf page: \u201c four = 1 AND unique1 = 42 \u201d , \u201c four = 2 AND unique1 = 42 \u201d , and \u201c four = 3 AND unique1 = 42 \u201d . This index is generally a good target for skip scan, since, as discussed in Section 11.3 , its leading column (the four column) contains only 4 distinct values, while its second/final column (the unique1 column) contains many distinct values."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..470.00 rows=7000 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/19/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 19beta4 \u00b7 using-explain", "sha256": "52f111fbd213e2200146319d01a9dcc2ea90001617d2a28edc52f7954c2dd70b"}, "paragraphs": ["Example copied from the PostgreSQL 19beta4 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/19/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 19beta4 \u00b7 using-explain", "sha256": "52f111fbd213e2200146319d01a9dcc2ea90001617d2a28edc52f7954c2dd70b"}, "paragraphs": ["Example copied from the PostgreSQL 19beta4 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "20": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "cba8bdfb7ca2a921f05c74fe0598cbac4e7b0dac0ee4b7f2095fe49d870e60bd", "archive_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=20", "label": "EXPLAIN"}, {"url": "/docs/devel/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/devel/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 20devel source archive", "label": "20devel", "major": "20", "channel": "devel", "revision": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41", "source_url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "source_snapshot_utc": "26-Sep-2026 20:22"}, "sources": [{"url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "line": 1589, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1589", "sha256": "13402758013520451539427b5993db06d463ca11c4e2d4cc5444e82367688077", "archive_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}, {"url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "5e39b2037bed672da55104229ecc32da5abde44c26bcad01479edcfa044d09ed", "archive_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}, {"url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "cba8bdfb7ca2a921f05c74fe0598cbac4e7b0dac0ee4b7f2095fe49d870e60bd", "archive_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}, {"url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "7a94ed1652f0d74d50c39971d1cd3e8051dbc0d6058f31b6de71a433ca343521", "archive_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}, {"url": "/docs/devel/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 20devel \u00b7 using-explain", "sha256": "99cfea3035876ea63f88b75ba8c964b51a32a70606544e09f769c0b60a234b31"}, {"url": "/docs/devel/using-explain.html#USING-EXPLAIN-ANALYZE", "path": "using-explain.html", "label": "PostgreSQL 20devel \u00b7 using-explain", "sha256": "99cfea3035876ea63f88b75ba8c964b51a32a70606544e09f769c0b60a234b31"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. That's because the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved using the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.90, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan.", "Here we see an Index-Only Scan node using tenk1_four_unique1_idx , a multi-column index on the tenk1 table's four and unique1 columns. The scan performs 3 searches that each read a single index leaf page: \u201c four = 1 AND unique1 = 42 \u201d , \u201c four = 2 AND unique1 = 42 \u201d , and \u201c four = 3 AND unique1 = 42 \u201d . This index is generally a good target for skip scan, since, as discussed in Section 11.3 , its leading column (the four column) contains only 4 distinct values, while its second/final column (the unique1 column) contains many distinct values."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..470.00 rows=7000 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/devel/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 20devel \u00b7 using-explain", "sha256": "99cfea3035876ea63f88b75ba8c964b51a32a70606544e09f769c0b60a234b31"}, "paragraphs": ["Example copied from the PostgreSQL 20devel manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/devel/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 20devel \u00b7 using-explain", "sha256": "99cfea3035876ea63f88b75ba8c964b51a32a70606544e09f769c0b60a234b31"}, "paragraphs": ["Example copied from the PostgreSQL 20devel manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}}}, "snapshot": {"facts": [{"label": "Core node tag", "value": "T_Unique"}, {"label": "Structured EXPLAIN Node Type", "value": "Unique"}, {"label": "Inputs", "value": "One sorted child plan"}, {"label": "Output", "value": "Distinct tuples"}, {"label": "Executor initializer", "value": "ExecInitUnique"}, {"label": "Memory mechanism", "value": "unclassified"}], "memory": {"evidence": [{"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "462de2b51c7c7501d5a83d1b5e4435ef9e752c1f1d1934c428f2d8577bd43e45", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}], "mechanism": "unclassified", "description": "This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.", "source_notes": []}, "tables": [{"key": "explain-labels", "rows": [{"label": "Unique", "identity": "Unique"}], "title": "EXPLAIN labels in this source build", "columns": [{"key": "label", "label": "Text-format label"}, {"key": "identity", "label": "Structured node identity"}]}], "related": [{"url": "/wiki/sql/explain/?v=18", "label": "EXPLAIN"}, {"url": "/docs/18/using-explain.html", "label": "Using EXPLAIN"}, {"url": "/docs/18/parallel-plans.html", "label": "Parallel plans"}], "release": {"ref": "PostgreSQL 18.6 source archive", "label": "18.6", "major": "18", "channel": "stable", "revision": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f", "source_url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "source_snapshot_utc": ""}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "line": 1577, "path": "src/backend/commands/explain.c", "label": "src/backend/commands/explain.c:1577", "sha256": "34c86d6070224a0e981efef51f79101d6d505e5874f1684ace183034bab14bb4", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "line": 350, "path": "src/backend/executor/execProcnode.c", "label": "src/backend/executor/execProcnode.c:350", "sha256": "f8a06a3f539077249b20664b2812433db6d7bd12b2c0ca633525db43d06f112a", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "path": "src/backend/executor/nodeUnique.c", "label": "src/backend/executor/nodeUnique.c", "sha256": "462de2b51c7c7501d5a83d1b5e4435ef9e752c1f1d1934c428f2d8577bd43e45", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "path": "src/include/nodes/plannodes.h", "label": "src/include/nodes/plannodes.h", "sha256": "52422b327a8049fbbb20d8b96008a0fc0a6fafa60f7eff3c695d5b2e83830120", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "/docs/18/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}, {"url": "/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}], "node_tag": "T_Unique", "sections": [{"title": "EXPLAIN names and attributes", "paragraphs": ["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.", "Text names recorded by this source: Unique.", "Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."]}, {"title": "Memory and temporary storage", "paragraphs": ["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider."]}, {"title": "Parallel execution and instrumentation", "paragraphs": ["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.", "Callbacks in this build: none extracted from this node implementation."]}, {"title": "Same-version manual discussion", "paragraphs": ["The added condition stringu1 = 'xxx' reduces the output row count estimate, but not the cost because we still have to visit the same set of rows. That's because the stringu1 clause cannot be applied as an index condition, since this index is only on the unique1 column. Instead it is applied as a filter on the rows retrieved using the index. Thus the cost has actually gone up slightly to reflect this extra checking.", "In this type of plan the table rows are fetched in index order, which makes them even more expensive to read, but there are so few that the extra cost of sorting the row locations is not worth it. You'll most often see this plan type for queries that fetch just a single row. It's also often used for queries that have an ORDER BY condition that matches the index order, because then no extra sorting step is needed to satisfy the ORDER BY . In this example, adding ORDER BY unique1 would use the same plan because the index already implicitly provides the requested ordering.", "In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or \u201c outer \u201d , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or \u201c inner \u201d child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.90, here), plus a little CPU time for join processing.", "The condition t1.hundred < t2.hundred can't be tested in the tenk2_unique2 index, so it's applied at the join node. This reduces the estimated output row count of the join node, but does not change either input scan.", "Here we see an Index-Only Scan node using tenk1_four_unique1_idx , a multi-column index on the tenk1 table's four and unique1 columns. The scan performs 3 searches that each read a single index leaf page: \u201c four = 1 AND unique1 = 42 \u201d , \u201c four = 2 AND unique1 = 42 \u201d , and \u201c four = 3 AND unique1 = 42 \u201d . This index is generally a good target for skip scan, since, as discussed in Section 11.3 , its leading column (the four column) contains only 4 distinct values, while its second/final column (the unique1 column) contains many distinct values."]}, {"title": "Examples from this manual build", "blocks": [{"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;\n\n                         QUERY PLAN\n------------------------------------------------------------\n Seq Scan on tenk1  (cost=0.00..470.00 rows=7000 width=244)\n   Filter: (unique1 < 7000)", "source": {"url": "/docs/18/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}, "paragraphs": ["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.", "Now let's modify the query to add a WHERE condition:"]}, {"code": "EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 < 100)\n   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 < 100)", "source": {"url": "/docs/18/using-explain.html#USING-EXPLAIN-BASICS", "path": "using-explain.html", "label": "PostgreSQL 18.6 \u00b7 using-explain", "sha256": "60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed"}, "paragraphs": ["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.", "Now, let's make the condition more restrictive:"]}]}, {"title": "Executor implementation notes", "paragraphs": ["nodeUnique.c Routines to handle unique'ing of queries where appropriate", "Unique is a very simple node type that just filters out duplicate tuples from a stream of sorted tuples from its subplan. It's essentially a dumbed-down form of Group: the duplicate-removal functionality is identical. However, Unique doesn't do projection nor qual checking, so it's marginally more efficient for cases where neither is needed. (It's debatable whether the savings justifies carrying two plan node types, though.)", "NOTES Assumes tuples returned from subplan arrive in sorted order.", "now loop, returning only non-duplicate tuples. We assume that the tuples arrive in sorted order so we can detect duplicates easily. The first tuple of each group is returned.", "Else test if the new tuple and the previously returned tuple match. If so then we loop back and fetch another new tuple from the subplan."]}, {"code": "case T_Unique:\n\t\t\tpname = sname = \"Unique\";\n\t\t\tbreak;", "title": "EXPLAIN identity in core source"}], "strategies": [], "description": ["Removes adjacent duplicates from a sorted input stream."], "evidence_kind": "source and documentation", "explain_names": ["Unique"], "partial_modes": [], "comparison_data": {"node_tag": "T_Unique", "strategies": [], "text_names": ["Unique"], "initializer": "ExecInitUnique", "partial_modes": [], "memory_mechanism": "unclassified", "parallel_callbacks": []}, "comparison_hash": "8fa24b0c3a61705b0b07250c27c004e5277482cfe2af4c65cce711d7ccac63f3", "explain_prefixes": ["Parallel", "Async"], "runtime_verified": false, "source_inventory": {"explain": "src/backend/commands/explain.c", "executor": "src/backend/executor/execProcnode.c", "implementation": "src/backend/executor/nodeUnique.c"}, "parallel_callbacks": []}, "comparison": {"left": "17", "right": "18", "status": "unchanged", "diff": ""}}