From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-patches(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: table/index fillfactor control, try 3 |
Date: | 2006-07-02 02:22:30 |
Message-ID: | 200607020222.k622MUE08602@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Patch applied. Thanks.
Catalog version updated.
---------------------------------------------------------------------------
ITAGAKI Takahiro wrote:
> This is the 3rd revised fillfactor patch.
> Now, AM specific options are stored in pg_class.reloptions as text[].
> Also, some bugs are fixed. It passed all regression tests.
>
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > An opaque bytea won't do though. What I'd suggest is something real
> > close to the format used for GUC parameters in ALTER DATABASE SET and
> > ALTER USER SET, ie, pairs of keyword/value strings. This way pg_dump
> > doesn't need very much smarts about what the values are that it's
> > dumping.
>
> The column format of options is changed from bytea to an array of text,
> so re-parsing is needed every time a connection accesses a relation.
> I changed to write pre-parsed options into pg_internal.init, but AFAICS,
> only system relations are written in it. If we will find the parsing
> is slow, it might be good to store options for user relations, too.
>
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
[ Attachment, skipping... ]
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-02 03:37:33 | Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) |
Previous Message | Bruce Momjian | 2006-07-02 02:00:47 | Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-02 03:37:33 | Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) |
Previous Message | Bruce Momjian | 2006-07-02 02:00:47 | Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) |