Re: sequences and "addval('myseq', value)" - Mailing list pgsql-hackers

From pgsql@mohawksoft.com
Subject Re: sequences and "addval('myseq', value)"
Date
Msg-id 16447.24.91.171.78.1086694789.squirrel@mail.mohawksoft.com
Whole thread Raw
In response to Re: sequences and "addval('myseq', value)"  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: sequences and "addval('myseq', value)"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> pgsql@mohawksoft.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.




pgsql-hackers by date:

Previous
From: "Thomas Hallgren"
Date:
Subject: Question regarding dynamic_library_path
Next
From: Jan Wieck
Date:
Subject: Re: Slony-I goes BETA (possible bug)