Hello all,
I think a good alternative was found and seems to be working fine. I really
do appreciate all the help and feedback.
Many thanks.
Regards,
Michael
Adrian Klaver schrieb am Di., 23. Jan. 2018 um
02:12 Uhr:
> On 01/22/2018 02:47 PM, Michael Krüger wrote:
> > Hello all,
> >
> > after c
On 01/22/2018 02:47 PM, Michael Krüger wrote:
Hello all,
after changing the function to this:
CREATE OR REPLACE FUNCTION multi_nextval(
use_seqname text,
use_increment integer)
RETURNS bigint
LANGUAGE 'plpgsql'
COST 100
VOLATILE
AS $BODY$
DECLARE
reply int8;
lock_i
On Mon, Jan 22, 2018 at 04:40:54PM -0700, David G. Johnston wrote:
>
> > I guess - the reason I'm a bit disappointed from the new behavior is that
> > we have used Postgresql for more than 10 years and it has never let us
> > down. We have been able to improve our product with every new release of
On Mon, Jan 22, 2018 at 3:47 PM, Michael Krüger
wrote:
>
> Is there any drawback to use setval compared to the ALTER SEQUENCE which I
> have used before? If not, then this could be the work around to go with as
> it has a similar performance to the original function.
>
Not that I can think of.
On 1/22/18 17:11, Michael Krüger wrote:
> I do not fully understand the reasoning of making sequences
> transactional in the first place.
It was sequence DDL that was made transactional. Sequence use is still
nontransactional.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Postgre
Hello all,
after changing the function to this:
CREATE OR REPLACE FUNCTION multi_nextval(
use_seqname text,
use_increment integer)
RETURNS bigint
LANGUAGE 'plpgsql'
COST 100
VOLATILE
AS $BODY$
DECLARE
reply int8;
lock_id int4;
seq_idx int8;
BEGIN
SELECT oid::int4 I
Hi Adrian and all,
I do not fully understand the reasoning of making sequences transactional
in the first place. As far as I know its also not done on Oracle or SQL
Server, but maybe I'm even wrong on that. What I question is a change in
behavior of existing functionality with such big impact, wit
On 01/22/2018 07:24 AM, Michael Krüger wrote:
Dear community,
I'm using PG10.1 on CentOS Linux release 7.4.1708 (Core) after upgrading
it from PG9.6.6. My application heavily uses sequences and requires
different increments of sequence numbers, e.g. a range of 100, 1000 or
5000 numbers, so it
Michael Krüger wrote:
> I'm using PG10.1 on CentOS Linux release 7.4.1708 (Core) after upgrading it
> from PG9.6.6.
> My application heavily uses sequences and requires different increments of
> sequence numbers,
> e.g. a range of 100, 1000 or 5000 numbers, so it is not possible to set a
> fixed
I also confirm this problem:
Running Michael's script on 10.1 takes 314 seconds instead of 2.3
seconds on 9.6.5.
Moreover adding some timing shows that on 10.1 the iteration execution
time grows linearly with each iteration. (!!)
If we remove ALTER SEQUENCE, the difference is only 2.5 times
On Mon, Jan 22, 2018 at 8:24 AM, Michael Krüger
wrote:
> Dear community,
>
> I'm using PG10.1 on CentOS Linux release 7.4.1708 (Core) after upgrading
> it from PG9.6.6. My application heavily uses sequences and requires
> different increments of sequence numbers, e.g. a range of 100, 1000 or 5000
why are you not using CACHE clause which is precisely for the purpose :
cache
The optional clause CACHE cache specifies how many sequence numbers are to be
preallocated and stored in memory for faster access. The minimum value is 1
(only one value can be generated at a time, i.e., no cache), and
Dear community,
I'm using PG10.1 on CentOS Linux release 7.4.1708 (Core) after upgrading it
from PG9.6.6. My application heavily uses sequences and requires different
increments of sequence numbers, e.g. a range of 100, 1000 or 5000 numbers,
so it is not possible to set a fixed increment on a sequ
13 matches
Mail list logo
