Re: fillfactor gets set to zero for toast tables

From: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fillfactor gets set to zero for toast tables
Date: 2010-06-01 00:50:22
Message-ID: 20100601095022.95C4.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-06-01 00:50:35 Re: is_absolute_path incorrect on Windows
Previous Message Bruce Momjian 2010-06-01 00:33:49 Re: Show schema name on REINDEX DATABASE