Extended customizing, SQL functions, internal variables, API

Поиск
Список
Период
Сортировка
От pgsql@mohawksoft.com
Тема Extended customizing, SQL functions, internal variables, API
Дата
Msg-id 16774.24.91.171.78.1085762789.squirrel@mail.mohawksoft.com
обсуждение исходный текст
Ответы Re: Extended customizing, SQL functions, internal variables, API
Список 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?


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: yet another contrib module
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SELECT * FROM LIMIT 1; is really slow