> "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
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
>
> [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
>
[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 dat
>
> [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
On Saturday 29 May 2004 20:48, [EMAIL PROTECTED] wrote:
> I was thinking that it could be done as a contrib/pgfoundary function. I
> think, but am not sure, that a function can be pre-loaded into the main
> postgresql backend (postmaster) prior to starting other connections. I'll
> have to check th
> 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 va
[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 thi
> 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
>> th
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:
> > 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"
On Friday 28 May 2004 04:08 pm, [EMAIL PROTECTED] wrote:
>
> No transactions.
>
Then it won't work. Let's say we take your example. The variable "s" is
supposed to be the sum of a column in a table.
When someone modifies the data in the table, when is "s" adjusted? What i
> 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 tran
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 n
I'm not really sure what to call this feature, but I have been talking to
a potential customer and they need a particular feature and they need to
to be very FAST.
Take this query:
select sum(num) from table;
Now, if that table is very large, this can take a lot of time.
Using a trigger, one ca
15 matches
Mail list logo
