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: 20060622142927.5220.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
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.


Regards,
---
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

Responses

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-2014 The PostgreSQL Global Development Group