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: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
