diff options
Diffstat (limited to 'doc/src/sgml/indexam.sgml')
| -rw-r--r-- | doc/src/sgml/indexam.sgml | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml index f8f3f1cc76..d559be0b6e 100644 --- a/doc/src/sgml/indexam.sgml +++ b/doc/src/sgml/indexam.sgml @@ -1,4 +1,4 @@ -<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.20 2007/01/20 23:13:01 tgl Exp $ --> +<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.21 2007/01/31 20:56:17 momjian Exp $ --> <chapter id="indexam"> <title>Index Access Method Interface Definition</title> @@ -33,7 +33,7 @@ block number and an item number within that block (see <xref linkend="storage-page-layout">). This is sufficient information to fetch a particular row version from the table. - Indexes are not directly aware that under MVCC, there may be multiple + Indexes are not directly aware that under MVCC, there might be multiple extant versions of the same logical row; to an index, each tuple is an independent object that needs its own index entry. Thus, an update of a row always creates all-new index entries for the row, even if @@ -174,7 +174,7 @@ aminsert (Relation indexRelation, <literal>heap_tid</> is the TID to be indexed. If the access method supports unique indexes (its <structname>pg_am</>.<structfield>amcanunique</> flag is true) then - <literal>check_uniqueness</> may be true, in which case the access method + <literal>check_uniqueness</> might be true, in which case the access method must verify that there is no conflicting row; this is the only situation in which the access method normally needs the <literal>heapRelation</> parameter. See <xref linkend="index-unique-checks"> for details. @@ -205,7 +205,7 @@ ambulkdelete (IndexVacuumInfo *info, <para> Because of limited <varname>maintenance_work_mem</>, - <function>ambulkdelete</> may need to be called more than once when many + <function>ambulkdelete</> might need to be called more than once when many tuples are to be deleted. The <literal>stats</> argument is the result of the previous call for this index (it is NULL for the first call within a <command>VACUUM</> operation). This allows the AM to accumulate statistics @@ -222,7 +222,7 @@ amvacuumcleanup (IndexVacuumInfo *info, </programlisting> Clean up after a <command>VACUUM</command> operation (zero or more <function>ambulkdelete</> calls). This does not have to do anything - beyond returning index statistics, but it may perform bulk cleanup + beyond returning index statistics, but it might perform bulk cleanup such as reclaiming empty index pages. <literal>stats</> is whatever the last <function>ambulkdelete</> call returned, or NULL if <function>ambulkdelete</> was not called because no tuples needed to be @@ -418,7 +418,7 @@ amrestrpos (IndexScanDesc scan); </para> <para> - The operator family may indicate that the index is <firstterm>lossy</> for a + The operator family can indicate that the index is <firstterm>lossy</> for a particular operator; this implies that the index scan will return all the entries that pass the scan key, plus possibly additional entries that do not. The core system's index-scan machinery will then apply that operator @@ -467,7 +467,7 @@ amrestrpos (IndexScanDesc scan); <para> The access method must support <quote>marking</> a position in a scan - and later returning to the marked position. The same position may be + and later returning to the marked position. The same position might be restored multiple times. However, only one position need be remembered per scan; a new <function>ammarkpos</> call overrides the previously marked position. @@ -480,7 +480,7 @@ amrestrpos (IndexScanDesc scan); would have found the entry if it had existed when the scan started, or for the scan to return such an entry upon rescanning or backing up even though it had not been returned the first time through. Similarly, - a concurrent delete may or may not be reflected in the results of a scan. + a concurrent delete might or might not be reflected in the results of a scan. What is important is that insertions or deletions not cause the scan to miss or multiply return entries that were not themselves being inserted or deleted. @@ -518,7 +518,7 @@ amrestrpos (IndexScanDesc scan); <literal>RowExclusiveLock</> when updating the index (including plain <command>VACUUM</>). Since these lock types do not conflict, the access method is responsible for handling any - fine-grained locking it may need. An exclusive lock on the index as a whole + fine-grained locking it might need. An exclusive lock on the index as a whole will be taken only during index creation, destruction, <command>REINDEX</>, or <command>VACUUM FULL</>. </para> @@ -537,7 +537,7 @@ amrestrpos (IndexScanDesc scan); <firstterm>heap</>) and the index. Because <productname>PostgreSQL</productname> separates accesses and updates of the heap from those of the index, there are windows in - which the index may be inconsistent with the heap. We handle this problem + which the index might be inconsistent with the heap. We handle this problem with the following rules: <itemizedlist> @@ -582,7 +582,7 @@ amrestrpos (IndexScanDesc scan); against this scenario by requiring the scan keys to be rechecked against the heap row in all cases, but that is too expensive. Instead, we use a pin on an index page as a proxy to indicate that the reader - may still be <quote>in flight</> from the index entry to the matching + might still be <quote>in flight</> from the index entry to the matching heap entry. Making <function>ambulkdelete</> block on such a pin ensures that <command>VACUUM</> cannot delete the heap entry before the reader is done with it. This solution costs little in run time, and adds blocking @@ -595,7 +595,7 @@ amrestrpos (IndexScanDesc scan); entry. This is expensive for a number of reasons. An <quote>asynchronous</> scan in which we collect many TIDs from the index, and only visit the heap tuples sometime later, requires much less index - locking overhead and may allow a more efficient heap access pattern. + locking overhead and can allow a more efficient heap access pattern. Per the above analysis, we must use the synchronous approach for non-MVCC-compliant snapshots, but an asynchronous scan is workable for a query using an MVCC snapshot. |