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
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? |