Mohawksoft,
One of the most common SQL database applications is as the backend of some
higher level system, like a web site. In these systems, ususlly done in
Java, PHP, or heaven help us, .NET, you have multiple front end machine
communicating with a SQL database backend.
Leaving aside that
Mohawksoft,
One of the most common SQL database applications is as the backend of
some
higher level system, like a web site. In these systems, ususlly done in
Java, PHP, or heaven help us, .NET, you have multiple front end machine
communicating with a SQL database backend.
Leaving aside
On Monday 30 August 2004 09:50, [EMAIL PROTECTED] wrote:
On Sun, Aug 29, 2004 at 09:24:59AM -0400, [EMAIL PROTECTED] wrote:
What's the advantage of instead stuffing these in-memory variables
into PostgreSQL? That it still works correctly and simply even if you
have a farm of 10 separate
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
On Sat, 28 Aug 2004 [EMAIL PROTECTED] wrote:
I don't see how this is different from CREATE TABLE shared_variables
(name
VARCHAR PRIMARY KEY, value VARCHAR) and
inserting/updating/deleting/selecting from that. Perhaps these are
per-session shared variables? IN which case, what is the
Josh Berkus [EMAIL PROTECTED] writes:
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
Greg Stark wrote:
I expect to see substantial resistance to incorporating such a feature. One
argument will be that he should simply use a separate system for such data.
For example, memcached would be much faster and more scalable than
communicating via postgres.
Postgres should do what
On Sun, Aug 29, 2004 at 09:24:59AM -0400, [EMAIL PROTECTED] wrote:
Think about a website shopping cart. The session and the things in the
cart don't matter after 10 or 15 minutes. Most of the time, it will just
be abandoned. The only time it is important is at checkout. At which point
it is
Mohawksoft,
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.
Hmmm, wait, are you
On Sat, 28 Aug 2004 [EMAIL PROTECTED] wrote:
I don't see how this is different from CREATE TABLE shared_variables
(name
VARCHAR PRIMARY KEY, value VARCHAR) and
inserting/updating/deleting/selecting from that. Perhaps these are
per-session shared variables? IN which case, what is the utility if
Jonathan,
The stuff that I contribute is often met with resistence, and that may or
may not be a good thing, but over the years, things I've said they NEEDED
to do, have been done and PostgreSQL is better for it.
Now don't think I'm talking trash to Tom either. These guys do a lot of
hard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 25 August 2004 02:15 pm, [EMAIL PROTECTED] wrote:
This is a first pass on a simple shared memory variable system for
PostgreSQL. I would appriciate anyone interested in this functionality to
rip it apart.
It basically adds this
I don't see how this is different from CREATE TABLE shared_variables
(name
VARCHAR PRIMARY KEY, value VARCHAR) and
inserting/updating/deleting/selecting from that. Perhaps these are
per-session shared variables? IN which case, what is the utility if
sharing
them across shared memory?
-
This is a first pass on a simple shared memory variable system for
PostgreSQL. I would appriciate anyone interested in this functionality to
rip it apart.
It basically adds this functionality:
SetShared('name', value);
GetSharedInt('name');
SetSharedText('name);
RemovedShared('name');
I also
LockShared('name');
[EMAIL PROTECTED] wrote:
This is a first pass on a simple shared memory variable system for
PostgreSQL. I would appriciate anyone interested in this functionality to
rip it apart.
It basically adds this functionality:
SetShared('name', value);
GetSharedInt('name');
LockShared('name');
Hmmm, I thought about that, but it is *WAY* more complicated than it
looks. What if after a Lock the process crashes before it can call
Unlock? It is this problem that inspired the add and sub calls.
[EMAIL PROTECTED] wrote:
This is a first pass on a simple shared
[EMAIL PROTECTED] wrote:
This is a first pass on a simple shared memory variable system for
PostgreSQL. I would appriciate anyone interested in this functionality to
rip it apart.
It basically adds this functionality:
SetShared('name', value);
GetSharedInt('name');
SetSharedText('name);
This new version contains, in addition to the previous version,
SwapShared(..) which allows you to swap a value in a variable.
sharedvar-040825.tgz
Description: application/unix-tar
---(end of broadcast)---
TIP 2: you can get off all lists at once
18 matches
Mail list logo
