Re: Indexam interface proposal

Added to TODO:
* Allow index scans to return matching index keys  http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php


---------------------------------------------------------------------------

Heikki Linnakangas wrote:
> Currently amgettuple returns one matching tuple at a time, in index 
> order. I'm proposing two changes to add support for
> - candidate matches
> - partial ordering
> 
> Those two features are essential to make clustered indexes work, and in 
> the future, binned bitmap indexes that don't have a bitmap for each 
> distinct value but for ranges of values.
> 
> There's a third feature looming in the future, that I haven't addressed:
> - returning index values, for index-only scans or at least for filtering 
> rows before fetching heap tuples.
> 
> 
> I'm proposing that we keep the one tuple per call nature of the 
> interface, but add a flag to mark candidate matches. index_getnext or 
> the executor would need to recheck the original quals for tuples marked 
> as candidates.
> 
> Another flag would be used to mean "this tuple marks the boundary of a 
> partial ordering". Let's call it boundary_mark for now.
> 
> For example, if an index scan returned tuples with the following keys, 
> with tuples on same line meaning the index doesn't know their relative 
> ordering.
> 
> 1
> 3 4 2
> 5 8 6 7
> 9
> 10
> 
> amgettuple would return the above tuples like this:
> 
> 1 3 4 2 5 8 6 7 9 10
> * *     *       * *
> 
> where the tuples marked with * would have the boundary_mark-flag set. If 
> the plan requires ordered results, index_getnext would have to sort 
> tuples between two markers before returning them to the caller.
> 
> amgetmulti would also need to have the candidate-flag added as I 
> proposed in the "Bitmapindexscan changes" patch I sent earlier to 
> pgsql-patches.
> 
> This interface change would solve much of the ugliness of my GIT patch, 
> by generalizing the index quals checking and sorting code to index_getnext.
> 
> Another source of ugliness in the patch is in inserting new tuples. 
> Inserts need to reach to the heap to fetch heap tuples, to compare keys 
> when splitting a group. I don't see a clean fix for that, but I don't 
> think it's as bad as the index scan code.
> 
> -- 
>    Heikki Linnakangas
>    EnterpriseDB   http://www.enterprisedb.com
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +