Re: autovacuum and reloptions

Поиск
Список
Период
Сортировка
От ITAGAKI Takahiro
Тема Re: autovacuum and reloptions
Дата
Msg-id 20081111121845.7BE9.52131E4D@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: autovacuum and reloptions  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: autovacuum and reloptions  (Euler Taveira de Oliveira <euler@timbira.com>)
Список 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@commandprompt.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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_do_encoding_conversion glitch
Следующее
От: Unicron
Дата:
Сообщение: another question i met during reviewing