Re: Contrib -- PostgreSQL shared variables

>> I think the shared variable module is another one of those things. The
>> cost overhead of a single variable implemented as a row is too high,
>> especially if you want to update it many times a second.
>
> Question: How will these "system variables" behave regarding
> transactions?
> If I update a system variable and roll back the transaction, does it
> change
> back? Do changes in a running transaction remain invisible until COMMIT?
> Excuse me if you've already answered these; I've not caught up on my
> -hackers
> backlog since I broke my foot.

Actually that are not involved with transactions in any way.

There classes of problems in which proper ACID implementation is not
nessisary. In fact, there are subclasses within a larger system that need
not have the overhead imposed by transactions.

Think about this:

In one part of the system, you update a table:

updated summary_table set sum = sum + $newvalue ;

In another part of the system you perform this:

select sum from summary_table;

You did this to keep from having to do:

select sum(col) from real_table;

Which, as everyone knows, can be millions of records, and a full table
scan would be too expensive.

In an active system there is *no* way that the results of these
transactions can be anything but an estimate or a snap shot. By the time
the results have been reported, the results surely would have changed.

In order to get this inaccurate information, you had to incure many dleted
rows in the summary table for each update or the cost of a full table
scan.

Usng the variable metaphor, the overall cost of doing this is almost nil.
With care, the results can be just as accurate with respect to time.

Like I said, it is *NOT* a general solution, but it *is* a solution a lot
of developers using databases have to implement *somewhere*, why not in
the database in which the data is stored?