Excerpts from Tom Lane's message of vie may 14 14:19:30 -0400 2010: > The problem is that if any reloption is set for the toast table, > we build a StdRdOptions struct in which fillfactor is zero, and > then all the code that actually uses fillfactor honors that. > And the reason fillfactor gets left as zero is that there is no > entry for it in the tables for toast-table reloptions. Clearly, > this wasn't thought through carefully enough.
Ouch :-( We messed with this stuff after the initial commit because I didn't get it right the first time either. I'm surprised that we didn't find this problem right away. > I'm inclined to think that we should remove the notion of there > being separate sets of rdoptions for heaps and toast tables --- > any case in which someone tries to omit a StdRdOption for toast > tables is going to fail the same way, unless we are fortunate > enough that zero is a desirable default. It doesn't seem like having the distinction has bought us anything. However, if we do that, we can't add a separate entry to intRelOpts to fix min/max/default to 100, so I think we should document that options for toast must match those for heaps. > What seems more rational is to provide toast.fillfactor but give it > min/max/default = 100. Adding an entry to intRelOpts should be enough to fix this bug, correct? -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
