Re: Contrib -- PostgreSQL shared variables

From: pgsql(at)mohawksoft(dot)com
To: josh(at)agliodbs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Contrib -- PostgreSQL shared variables
Date: 2004-08-31 01:40:47
Message-ID: 17358.24.91.171.78.1093916447.squirrel@mail.mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 Java, .NET and even PHP5 have much more sophisticated
> ways
> of sharing variables ...

Yes, and hows does a developer share between PHP, Java, and .NET? Yes, in
a homogenous system that may work, but not across multiple systems, and
that still doesn't address the data being 'in' the database as opposed to
some other system.

>
>> These systems use the database as the main data server. The overall
>> scalability of their system is based on the scalability of the database.
>> At some point, you'll max out the DB and be stuck. The shared variables
>> module is designed to allow you to scale better by allowing you to
>> cheapy
>> maintain data.
>
> I really don't follow how this makes a lack of transaction-awareness for
> these
> global variables an advantage. If you're saying that it's not possible
> to
> make shared variables which are both cheap and transaction-aware, then say
> so
> and be clear about it.
>
> Please understand that I am not opposed to the idea behind the shared
> variable
> proposal. I just think there are some details to be worked out.

You won't understand it from what you quoted because the reasoning has
been snipped, and I've posted the example so many times my fingers are
sore.

Some data does not need to be transactional. Data that does not need to be
transactional does not need to be transactional. If overhead can be
reduced or eliminated by eliminating transactional procedures for data
which does not need it, then the database scales better. Isn't that
completely obvious?

If your system is bonking out, every last bit of efficiency is important.
(And this is no small efficiency!) It is these sorts of tricks that can
make the difference between a well working site, and one that looks like
it has been slashdotted.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2004-08-31 01:58:32 Re: Contrib -- PostgreSQL shared variables
Previous Message Christopher Kings-Lynne 2004-08-31 01:16:04 Re: Regarding insertion of Unicode String in Postgres using