fillfactor gets set to zero for toast tables
in [PgSql]
|
Prev: Generalized Inverted Generalized Search Tree
Next: [HACKERS] Generating Lots of PKs with nextval(): A Feature Proposal
From: Tom Lane on 31 May 2010 15:01 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Excerpts from Takahiro Itagaki's message of mié may 26 03:32:56 -0400 2010: >> 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. > Do we really need default_only entries in user-defined reloptions? > We have yet to see any indication that anybody is using user-defined > reloptions at all ... It'd be good to have an use case at least (if > only to ensure that the API we're providing is sufficient). There probably isn't anyone using them, yet, which seems to me to be a good argument to fix any obvious deficiencies in the API *now* before there actually is anyone who'll be affected. In particular, I suggest that 9.0 would be a good time to add an "int flags" parameter to the add_xxx_reloption functions. The first flag could be default_only and we'd have room to add more later without another API break. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 31 May 2010 14:54 Excerpts from Takahiro Itagaki's message of mié may 26 03:32:56 -0400 2010: > > Alvaro Herrera <alvherre(a)commandprompt.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. Do we really need default_only entries in user-defined reloptions? We have yet to see any indication that anybody is using user-defined reloptions at all ... It'd be good to have an use case at least (if only to ensure that the API we're providing is sufficient). If in the future we determine that we need to offer user-defined default_only reloptions, perhaps we can add new entry points in the reloptions API. -- Álvaro Herrera <alvherre(a)commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Takahiro Itagaki on 31 May 2010 20:50 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre(a)commandprompt.com> writes: > > Do we really need default_only entries in user-defined reloptions? I think we don't, but I also think we don't need it at all even in the core because it just set a few variables to the default values with complex code flow. Could you explain why default_only entries idea is better than adjusting those fields in the toast-specific codes? It's my understanding that reloption-framework is just a tool to fill reloption parameters, and it's not responsible for unused fields. > > We have yet to see any indication that anybody is using user-defined > > reloptions at all ... It'd be good to have an use case at least (if > > only to ensure that the API we're providing is sufficient). I use it my textsearch_senna extension :-). But I don't need default_only entries at this time. > I suggest that 9.0 would be a good time to add an "int flags" parameter > to the add_xxx_reloption functions. The first flag could be > default_only and we'd have room to add more later without another API > break. I agree the idea when we reach a conclusion to introduce default_only. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Takahiro Itagaki on 4 Jun 2010 00:08
Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> wrote: > Could you explain why default_only entries idea is > better than adjusting those fields in the toast-specific codes? > It's my understanding that reloption-framework is just a tool to fill > reloption parameters, and it's not responsible for unused fields. Here is my proposal to fix the issue. I didn't introduce default_only field but simply adjust parameters for TOAST reloptions. BTW, not only heap and toast relations but also btree, hash, and gist indexes use StdRdOptions. However, they actually don't support autovacuum options. So, StdRdOptions is a bloated all-in-one descriptor now. Instead, they should use fillfactor-only reloptions that is defined separately from options for heap. Regards, --- Takahiro Itagaki NTT Open Source Software Center |