Extended customizing, SQL functions, internal variables, API

From: pgsql(at)mohawksoft(dot)com
To: pgsql-hackers(at)postgresql(dot)org
Subject: Extended customizing, SQL functions, internal variables, API
Date: 2004-05-28 16:46:29
Message-ID: 16774.24.91.171.78.1085762789.squirrel@mail.mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm not really sure what to call this feature, but I have been talking to
a potential customer and they need a particular feature and they need to
to be very FAST.

Take this query:

select sum(num) from table;

Now, if that table is very large, this can take a lot of time.

Using a trigger, one can update a summary table for changes, i.e. delete,
update, insert. Problem with this is each transaction to the summary table
creates a new row. If you are doing a 100 updates, inserts, deletes a
second, this soon starts to take a long time to access.

Frequent vacuuming now has to happen.

It occurs to me that there is a need for internal state variables that can
be accessed either by functions or something similar.

At PostgreSQL start time, some subsystem allocates and initializes
internal variables. Child processes of PostgreSQL, have this sort of
metaphore:

>>>>>>>>>>> VAR.c >>>>>>>>>>>>>

/* called at init time, create var if nessisary */
PGVAR *var = var_allocate('varname', size);

if( var_lock(var) )
{
/* do something worth while */

var_unlock(var);
}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

>>>>>>>>>>> VAR.sql >>>>>>>>>
SELECT var_varname;

Does anyone see a need for this?

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-05-28 16:48:40 Re: Win32, PITR, nested transactions, tablespaces
Previous Message Tom Lane 2004-05-28 16:44:35 Re: list rewrite committed