Skip site navigation (1) Skip section navigation (2)

table/index fillfactor control, try 3

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: pgsql-patches(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: table/index fillfactor control, try 3
Date: 2006-06-22 05:58:52
Message-ID: (view raw or whole thread)
Lists: pgsql-hackerspgsql-patches
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.

ITAGAKI Takahiro
NTT Open Source Software Center

Attachment: fillfactor-0622.sql
Description: application/octet-stream (1.4 KB)
Attachment: fillfactor-0622.patch.gz
Description: application/octet-stream (33.9 KB)

In response to


pgsql-hackers by date

Next:From: Marc G. FournierDate: 2006-06-22 06:31:15
Subject: Re: let's meet
Previous:From: Qingqing ZhouDate: 2006-06-22 04:40:58
Subject: Re: Problem to "current-status information in shared memory" patch

pgsql-patches by date

Next:From: Hiroshi SaitoDate: 2006-06-22 13:37:28
Subject: MS-VC build patch
Previous:From: Bruce MomjianDate: 2006-06-22 02:13:03
Subject: Re: Overhead for stats_command_string et al, take 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group