Re: user defined settings (aka user defined guc variables)

From: Joe Conway <mail(at)joeconway(dot)com>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: user defined settings (aka user defined guc variables)
Date: 2002-12-19 02:02:56
Message-ID: 3E0128D0.40004@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gavin Sherry wrote:
> On Wed, 18 Dec 2002, Bruce Momjian wrote:
>
>
>>What exactly can you do with these variables other than SHOW/SET. Seems
>>it would be nice if they could be used in queries, like in a special
>>table like sysvar:
>>
>> SELECT sysvar.fsync;
>
>
> Isn't that just identical to having a table?

Well you can use it in a query:

regression=# select pg_create_user_setting('myvar',17,false);
pg_create_user_setting
------------------------
17
(1 row)

regression=# select typname from pg_type where oid = current_setting('myvar');
typname
---------
bytea
(1 row)

There are at least two differences to this approach vs a table:

1. Main reason is that if a user defined function/contrib module creates a
table in my database I consider that too intrusive. I'd prefer not to have
metadata tables in my database simply to support a loaded function.

2. It's faster. In some simple tests, I found that getting a setting value via
current_setting('myvar') is about 40% faster than getting a value from a one
row table, and about 100% faster than an indexed lookup in a larger table
(after the table is cached, more than that on the first lookup).

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-12-19 02:14:13 Fancy ADD COLUMN
Previous Message Noel Faux 2002-12-19 01:51:06 Re: error when using move, any suggestions?