From: | pgsql(at)mohawksoft(dot)com |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sequences and "addval('myseq', value)" |
Date: | 2004-06-08 11:39:49 |
Message-ID: | 16447.24.91.171.78.1086694789.squirrel@mail.mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> pgsql(at)mohawksoft(dot)com writes:
>> Anyway, I'm not quite getting the idea of caching sequence values. I
>> understand the performance benefits, but it seems problematic across
>> multiple backends, almost ensuring "holes" in the sequence of numbers.
>
> The point is to reduce lock contention on the sequence table. Since
> lack-of-holes is explicitly *not* a design goal, there is no downside
> that I see.
>
I knew that, but it wasn't until I thought of using a sequence as a shared
variable that it sort of hit me.
The question is, what do you think of an "addval" function for sequences.
As used:
Executed in a trigger:
select addval('mysum', val);
Executed:
select currval('mysum');
Instead of:
select sum(val) from largetable;
The problem I, and I know many other people are having, is that large sums
can not be obtained without a table scan. A summary table can be created,
but if you have any sort of volume, you have to vacuum the summary table
constantly.
Using the sequence construct as sort of an accumulator just might fit the
bill for this sort of thing.
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2004-06-08 12:34:59 | Re: Slony-I goes BETA (possible bug) |
Previous Message | Magnus Hagander | 2004-06-08 08:27:29 | Re: [pgsql-hackers-win32] Failures with windows port |