database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-31 22:04:40 +03:00
Code Activity

Clean up API for ambulkdelete/amvacuumcleanup as per today's discussion.

Browse Source 
This formulation requires every AM to provide amvacuumcleanup, unlike before,
but it's surely a whole lot cleaner.  Also, add an 'amstorage' column to
pg_am so that we can get rid of hardwired knowledge in DefineOpClass().
This commit is contained in:
Tom Lane
2006-05-02 22:25:10 +00:00
parent d3171dd64b
commit e57345975c
16 changed files with 334 additions and 399 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/sgml/catalogs.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.121 2006/03/10 19:10:46 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.122 2006/05/02 22:25:09 tgl Exp $ -->
<!--
Documentation of the system catalogs, directed toward PostgreSQL developers
-->
@ -394,6 +394,13 @@
<entry>Does the access method support null index entries?</entry>
</row>
<row>
<entry><structfield>amstorage</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Can index storage data type differ from column data type?</entry>
</row>
<row>
<entry><structfield>amconcurrent</structfield></entry>
<entry><type>bool</type></entry>
@ -401,6 +408,13 @@
<entry>Does the access method support concurrent updates?</entry>
</row>
<row>
<entry><structfield>amclusterable</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Can an index of this type be CLUSTERed on?</entry>
</row>
<row>
<entry><structfield>aminsert</structfield></entry>
<entry><type>regproc</type></entry>

46
doc/src/sgml/indexam.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.9 2006/03/10 19:10:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.10 2006/05/02 22:25:09 tgl Exp $ -->
<chapter id="indexam">
<title>Index Access Method Interface Definition</title>
@ -184,44 +184,52 @@ aminsert (Relation indexRelation,
<para>
<programlisting>
IndexBulkDeleteResult *
ambulkdelete (Relation indexRelation,
ambulkdelete (IndexVacuumInfo *info,
IndexBulkDeleteResult *stats,
IndexBulkDeleteCallback callback,
void *callback_state);
</programlisting>
Delete tuple(s) from the index. This is a <quote>bulk delete</> operation
that is intended to be implemented by scanning the whole index and checking
each entry to see if it should be deleted.
The passed-in <literal>callback</> function may be called, in the style
The passed-in <literal>callback</> function must be called, in the style
<literal>callback(<replaceable>TID</>, callback_state) returns bool</literal>,
to determine whether any particular index entry, as identified by its
referenced TID, is to be deleted. Must return either NULL or a palloc'd
struct containing statistics about the effects of the deletion operation.
It is OK to return NULL if no information needs to be passed on to
<function>amvacuumcleanup</>.
</para>
<para>
If <literal>callback_state</> is NULL then no tuples are to be deleted.
The index AM may choose to optimize this case (eg by not scanning the
index) but it is still expected to deliver accurate statistics.
Because of limited <varname>maintenance_work_mem</>,
<function>ambulkdelete</> may 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
across the whole operation. Typically, <function>ambulkdelete</> will
modify and return the same struct if the passed <literal>stats</> is not
null.
</para>
<para>
<programlisting>
IndexBulkDeleteResult *
amvacuumcleanup (Relation indexRelation,
IndexVacuumCleanupInfo *info,
amvacuumcleanup (IndexVacuumInfo *info,
IndexBulkDeleteResult *stats);
</programlisting>
Clean up after a <command>VACUUM</command> operation (one or more
<function>ambulkdelete</> calls). An index access method does not have
to provide this function (if so, the entry in <structname>pg_am</> must
be zero). If it is provided, it is typically used for bulk cleanup
such as reclaiming empty index pages. <literal>info</>
provides some additional arguments such as a message level for statistical
reports, and <literal>stats</> is whatever the last
<function>ambulkdelete</> call returned. <function>amvacuumcleanup</>
may replace or modify this struct before returning it. If the result
is not NULL it must be a palloc'd struct. The statistics it contains
will be reported by <command>VACUUM</> if <literal>VERBOSE</> is given.
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
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
deleted. If the result is not NULL it must be a palloc'd struct.
The statistics it contains will be used to update <structname>pg_class</>,
and will be reported by <command>VACUUM</> if <literal>VERBOSE</> is given.
It is OK to return NULL if the index was not changed at all during the
<command>VACUUM</command> operation, but otherwise correct stats should
be returned.
</para>
<para>