>> http://archives.postgresql.org/pgsql-hackers/2005-09/msg00851.php
>
> Just to follow up on the discussion of that thread: what's been
> implemented is a way to store arbitrary name=value strings in an index's
> pg_class entry, and to make these available in a pre-parsed form through
> the index relcache entry. However you'd have to be cautious about using
> the values directly for any fundamental index structure decisions,
> because ALTER INDEX will just change them without giving you an
> opportunity to modify the index in response. So depending on what you
> are doing, you might need to store the "real" values in the index
> metapage, and set those values from the reloptions parameters only at
> ambuild() time. This would mean that ALTER INDEX + REINDEX would be the
I see. There is one more problem: pluggable parameters for index. For example,
the parameter needed for tsearch2 (size of signature) isn't useful for others
modules/opclasses. Another issue, GiST (and GIN too) doesn't have metapage at
all for now, it's not a problem, but until now it wasn't needed. I think, we may
can add to pg_opclass's definition method/parameter name and create some API
(may be, index specific) to propagate parameter's to module's interface
functions to index.
> Also: as of CVS tip ginoptions() accepts FILLFACTOR but nothing is done
> with it. Can you do something useful with FILLFACTOR in GIN?
Now GIN is nested B-Tree: B-tree for entries (lexemes for tsearch2) and B-Tree
for ItemPointers per entry if entry is popular enough. So fillfactor may be used
as usual.
Small advertising :) : http://www.sigaev.ru/gin/GinStructure.pdf
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
