diff options
author | Andres Freund <andres@anarazel.de> | 2019-03-30 20:18:53 -0700 |
---|---|---|
committer | Andres Freund <andres@anarazel.de> | 2019-03-31 18:37:57 -0700 |
commit | 73c954d24896aeb05de0f81d75e891a858e439e9 (patch) | |
tree | fd4ef1ff3c9b695b061ea3180ecda8fbea8c8b9b /doc/src | |
parent | 4bb50236eb561f4639e75a393a5a1c9b8681acfb (diff) | |
download | postgresql-73c954d24896aeb05de0f81d75e891a858e439e9.tar.gz postgresql-73c954d24896aeb05de0f81d75e891a858e439e9.zip |
tableam: sample scan.
This moves sample scan support to below tableam. It's not optional as
there is, in contrast to e.g. bitmap heap scans, no alternative way to
perform tablesample queries. If an AM can't deal with the block based
API, it will have to throw an ERROR.
The tableam callbacks for this are block based, but given the current
TsmRoutine interface, that seems to be required.
The new interface doesn't require TsmRoutines to perform visibility
checks anymore - that requires the TsmRoutine to know details about
the AM, which we want to avoid. To continue to allow taking the
returned number of tuples account SampleScanState now has a donetuples
field (which previously e.g. existed in SystemRowsSamplerData), which
is only incremented after the visibility check succeeds.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
Diffstat (limited to 'doc/src')
-rw-r--r-- | doc/src/sgml/tablesample-method.sgml | 9 |
1 files changed, 4 insertions, 5 deletions
diff --git a/doc/src/sgml/tablesample-method.sgml b/doc/src/sgml/tablesample-method.sgml index b84b7ba8855..880e42c9509 100644 --- a/doc/src/sgml/tablesample-method.sgml +++ b/doc/src/sgml/tablesample-method.sgml @@ -227,7 +227,7 @@ BeginSampleScan (SampleScanState *node, <para> <programlisting> BlockNumber -NextSampleBlock (SampleScanState *node); +NextSampleBlock (SampleScanState *node, BlockNumber nblocks); </programlisting> Returns the block number of the next page to be scanned, or @@ -262,10 +262,9 @@ NextSampleTuple (SampleScanState *node, numbers in the range <literal>1 .. maxoffset</literal> actually contain valid tuples. This is not normally a problem since the core code ignores requests to sample missing or invisible tuples; that should not result in - any bias in the sample. However, if necessary, the function can - examine <literal>node->ss.ss_currentScanDesc->rs_vistuples[]</literal> - to identify which tuples are valid and visible. (This - requires <literal>node->use_pagemode</literal> to be <literal>true</literal>.) + any bias in the sample. However, if necessary, the function can use + <literal>node->donetuples</literal> to examine how many of the tuples + it returned were vlaid and visible. </para> </note> |