Re: sequences and "addval('myseq', value)"

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.

In response to

Responses

Browse pgsql-hackers by date

  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