table/index fillfactor control, try 2

This is a revised fillfactor patch. It uses WITH syntax and
we can add new AM specific parameters easily.

Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> I see what Tom was driving at with earlier comments. I think we need an
> non-index AM specific patch, so that each AM has its own parameters.

I added amparseoption and amdumpoption to pg_am. The amparseoption parses
options and convert them to an internal structure per AM. The amdumpoption
converts the structure to a human-readable text to dump the definition.
It might be better to make the result of amdumpoption to be a list of
(name, value) pairs instead of a plain text.

> So we have a new element of the RelationData struct:
> void *rd_amopts;
> Which each AM defines and interprets.

The internal structure is stored in the pg_class.relamopaque column as bytea.
I guess it is not the best and there is room for discussion. I examined the
following ideas, but they had complexities and difficulties.

1. Add AM specific system tables (pg_heap, pg_btree, etc.) that may inherit
pg_class. But it will impact the current source code terribly.
2. Store the structures in AM's meta page. But heaps don't have meta pages.
3. Store them into an array of text column that newly added to pg_class.
But we hove to re-parse the array every time relations are loaded.
4. Add new system table, pg_class_option (relid, option name, value).
But it has same problem as 3 and needs additional heap scannings.

Therefore, I choose the as-is binary format to store the internal structures.
Any comments or better ideas?

---
ITAGAKI Takahiro
NTT Open Source Software Center