Re: autovacuum and reloptions

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autovacuum and reloptions
Date: 2008-11-11 03:28:20
Message-ID: 20081111121845.7BE9.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I have a comment about reloptions of autovacuum parameters:
I'd like to have an easier way to extract individual parameters.

Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:

> Euler Taveira de Oliveira wrote:
> > What did I already do? I refactored reloptions.c to support multiple
> > options. I tried to follow up the same way GUC do (of course, it is much
> > simpler). I'm thinking about removing (replacing?) StdRdOptions 'cause
> > we need a different struct to store reloptions. Suggestions?
> Interesting.

We store reloptions as an array of 'key=value' text, but there is
no official way to read each parameter. I always create an user
defined function to extract fillfactors, but it would be better
if we have a standard method to do that.

---- [brute force way]
CREATE FUNCTION pg_fillfactor(reloptions text[], relam OID)
RETURNS integer AS
$$
SELECT (regexp_matches(array_to_string($1, '/'),
'fillfactor=([0-9]+)'))[1]::integer AS fillfactor
UNION ALL
SELECT CASE $2
WHEN 0 THEN 100 -- heap
WHEN 403 THEN 90 -- btree
WHEN 405 THEN 70 -- hash
WHEN 783 THEN 90 -- gist
WHEN 2742 THEN 100 -- gin
END
LIMIT 1;
$$
LANGUAGE sql STABLE;
----

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Unicron 2008-11-11 03:40:29 another question i met during reviewing
Previous Message Bruce Momjian 2008-11-11 03:12:43 Re: db_user_namespace, md5 and changing passwords