From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fillfactor gets set to zero for toast tables |
Date: | 2010-05-14 18:56:55 |
Message-ID: | 1273862584-sup-9480@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-05-14 19:03:57 | Re: fillfactor gets set to zero for toast tables |
Previous Message | Peter Crabtree | 2010-05-14 18:56:18 | Generating Lots of PKs with nextval(): A Feature Proposal |