From 2166aa51840094f4b738f4a9af1ad6bd94a97cff Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Mon, 18 Apr 2022 10:13:09 -0500 Subject: [PATCH v2022051001 1/2] doc: ANDed and ORed --- doc/src/sgml/indexam.sgml | 2 +- doc/src/sgml/indices.sgml | 4 ++-- doc/src/sgml/logical-replication.sgml | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml index d4163c96e9f..16669f4086a 100644 --- a/doc/src/sgml/indexam.sgml +++ b/doc/src/sgml/indexam.sgml @@ -843,7 +843,7 @@ amparallelrescan (IndexScanDesc scan); constant, where the index key is one of the columns of the index and the operator is one of the members of the operator family associated with that index column. An index scan has zero or more scan - keys, which are implicitly ANDed — the returned tuples are expected + keys, which are implicitly AND-ed — the returned tuples are expected to satisfy all the indicated conditions. diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml index 023157d8884..890c6d3451c 100644 --- a/doc/src/sgml/indices.sgml +++ b/doc/src/sgml/indices.sgml @@ -597,7 +597,7 @@ CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST); a query like WHERE x = 42 OR x = 47 OR x = 53 OR x = 99 could be broken down into four separate scans of an index on x, each scan using one of the query clauses. The results of these scans are - then ORed together to produce the result. Another example is that if we + then OR-ed together to produce the result. Another example is that if we have separate indexes on x and y, one possible implementation of a query like WHERE x = 5 AND y = 6 is to use each index with the appropriate query clause and then AND together @@ -608,7 +608,7 @@ CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST); To combine multiple indexes, the system scans each needed index and prepares a bitmap in memory giving the locations of table rows that are reported as matching that index's conditions. - The bitmaps are then ANDed and ORed together as needed by the query. + The bitmaps are then AND-ed and OR-ed together as needed by the query. Finally, the actual table rows are visited and returned. The table rows are visited in physical order, because that is how the bitmap is laid out; this means that any ordering of the original indexes is lost, and diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml index 145ea71d61b..d2939fec71c 100644 --- a/doc/src/sgml/logical-replication.sgml +++ b/doc/src/sgml/logical-replication.sgml @@ -477,7 +477,7 @@ If the subscription has several publications in which the same table has been published with different row filters (for the same publish - operation), those expressions get ORed together, so that rows satisfying + operation), those expressions get OR-ed together, so that rows satisfying any of the expressions will be replicated. This means all the other row filters for the same table become redundant if: -- 2.17.1