From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fillfactor gets set to zero for toast tables |
Date: | 2010-05-26 07:32:56 |
Message-ID: | 20100526163256.B28E.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Tom Lane's message of vie may 14 15:03:57 -0400 2010:
>
> > Maybe a better solution is to have some kind of notion of a default-only
> > entry, which is sufficient to insert the default into the struct but
> > isn't accepted as a user-settable item.
>
> This patch (for 8.4, but applies fuzzily to 9.0) implements this idea.
> Note that there's no explicit check that every heap option has a
> corresponding toast option; that's left to the developer's judgement to
> add. I added the new member to relopt_gen struct so that existing
> entries did not require changes in initializers.
The new "default_only" field can be initialized only from the internal codes
and is not exported to user definded reloptions. We could add an additional
argument to add_xxx_reloption() functions, but it breaks ABI.
How about the attached patch? It just fills fillfactor (and analyze_threshold)
to default values for TOAST relations. I think responsibility for filling
reloptions with proper values is not in the generic option routines but in
AM-specific reloption handlers.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
toast-ff-fix.patch | application/octet-stream | 1019 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-05-26 08:02:07 | Open items related to SR |
Previous Message | KaiGai Kohei | 2010-05-26 06:50:56 | Re: ExecutorCheckPerms() hook |