pgsql == pgsql [EMAIL PROTECTED] writes:
pgsql The have a database of information that is coming in at a
pgsql high speed regular basis. One bit of information is a
pgsql value. To get this value they must perform SELECT
pgsql sum(field) FROM table. Well, this simply does not
On Saturday 29 May 2004 18:10, [EMAIL PROTECTED] wrote:
Having internal PostgreSQL variables that are not present on disk, or
maybe, variables that are mirrored on disk may be good.
Yes. I agree. I can see why you proposed no transactions few posts ago. Take
an example of a count variable. It
On Saturday 29 May 2004 04:38, [EMAIL PROTECTED] wrote:
Now, I could roll my own system pretty easily, and probably will do so. It
won't take too much, however, it would be neat if this was in PostgreSQL.
I fully expect that people would worry about this, and I don't blame them.
It is a *bad*
On Saturday 29 May 2004 04:38, [EMAIL PROTECTED] wrote:
Now, I could roll my own system pretty easily, and probably will do so.
It
won't take too much, however, it would be neat if this was in
PostgreSQL.
I fully expect that people would worry about this, and I don't blame
them.
It is a
[EMAIL PROTECTED] writes:
Having internal PostgreSQL variables that are not present on disk, or
maybe, variables that are mirrored on disk may be good.
I don't think there's anything wrong with your idea, and there are numerous
good solutions that implement it already. But what makes you
On Saturday 29 May 2004 18:10, [EMAIL PROTECTED] wrote:
Having internal PostgreSQL variables that are not present on disk, or
maybe, variables that are mirrored on disk may be good.
Yes. I agree. I can see why you proposed no transactions few posts ago.
Take
an example of a count variable.
[EMAIL PROTECTED] writes:
Having internal PostgreSQL variables that are not present on disk, or
maybe, variables that are mirrored on disk may be good.
I don't think there's anything wrong with your idea, and there are
numerous
good solutions that implement it already. But what makes you
[EMAIL PROTECTED] writes:
I agree completely with one caveat, when the best tool for the job lacks a
feature what do you do?
You're missing the point. The feature you want has nothing to do with
relational databases. It has everything to do with in-memory non-transactional
non-relational
[EMAIL PROTECTED] writes:
I agree completely with one caveat, when the best tool for the job lacks
a
feature what do you do?
You're missing the point. The feature you want has nothing to do with
relational databases. It has everything to do with in-memory
non-transactional
On Fri, May 28, 2004 at 12:46:29 -0400,
[EMAIL PROTECTED] wrote:
It occurs to me that there is a need for internal state variables that can
be accessed either by functions or something similar.
But there still needs to be multiple copies to take into account that
different transactions may
On Fri, May 28, 2004 at 12:46:29 -0400,
[EMAIL PROTECTED] wrote:
It occurs to me that there is a need for internal state variables that
can
be accessed either by functions or something similar.
But there still needs to be multiple copies to take into account that
different transactions
[EMAIL PROTECTED] writes:
On Fri, May 28, 2004 at 12:46:29 -0400,
[EMAIL PROTECTED] wrote:
It occurs to me that there is a need for internal state variables that
can be accessed either by functions or something similar.
What you're describing is called materialized views and indeed a
12 matches
Mail list logo
