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 sep
> 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.
>
> Le
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 t
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 impl
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 i
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 postgr
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
> 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
>> 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 upd
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
> ha
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
s
> 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 memor
-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 f
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 w
[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);
RemovedShar
> 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
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');
SetSharedText
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 add
18 matches
Mail list logo
