Prev: recovery consistent != hot standby
Next: Parameter oddness; was HS/SR Assert servercrash
From: Tom Lane on 14 May 2010 17:27
Peter Crabtree <peter.crabtree(a)gmail.com> writes:
> Now, I was reminded that I could simply do this:

> SELECT nextval('my_seq') FROM generate_series(1, 500);

> But of course then I would have no guarantee that I would get a
> contiguous block of ids,

The existing "cache" behavior will already handle that for you,
I believe. I don't really see a need for new features here.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 14 May 2010 17:29
On Fri, May 14, 2010 at 5:04 PM, hubert depesz lubaczewski
<depesz(a)depesz.com> wrote:
> On Fri, May 14, 2010 at 02:07:27PM -0500, Kenneth Marshall wrote:
>> Hi Peter,
>>
>> All you need to do is define your own sequence with an
>> increment of 500. Look at:
>>
>> http://www.postgresql.org/docs/8.4/static/sql-createsequence.html
>
> This is often not enough. For example - I want standard increment of 1,
> but right now I'm importing 10000 objects, and it would be simpler for
> me to get 10000 ids. Preferably in one block.
>
> This is not achievable now. I know I can 'alter sequence set increment
> by' - but this will also affect concurrent sessions. which might not be
> a problem, but it's a side effect that I don't want.
>
> +1 for original proposition, would love to get it.

If we do this, I'm inclined to think that the extra argument to
nextval() should be treated as overriding the base increment rather
than specifying a multiplier for it. Other than that nitpick, it
sounds like a reasonable thing to allow.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Crabtree on 14 May 2010 17:52
On Fri, May 14, 2010 at 5:27 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Peter Crabtree <peter.crabtree(a)gmail.com> writes:
>> Now, I was reminded that I could simply do this:
>
>> SELECT nextval('my_seq') FROM generate_series(1, 500);
>
>> But of course then I would have no guarantee that I would get a
>> contiguous block of ids,
>
> The existing "cache" behavior will already handle that for you,
> I believe. I don't really see a need for new features here.

I don't see how that works for this case, because the "cache" setting
is "static", and also shared between sessions. So if I have 10 records
one time, and 100 records the next, and 587 the third time, what
should my CACHE be set to for that sequence?

And if I do ALTER SEQUENCE SET CACHE each time, I have either killed
concurrency (because I'm locking other sessions out of using that
sequence until I'm finished with it), or I have a race condition (if
someone else issues an ALTER SEQUENCE before I call nextval()). The
same problem exists with using ALTER SEQUENCE SET INCREMENT BY.

Peter

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Crabtree on 14 May 2010 17:58
On Fri, May 14, 2010 at 5:29 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On Fri, May 14, 2010 at 5:04 PM, hubert depesz lubaczewski
> <depesz(a)depesz.com> wrote:
>> On Fri, May 14, 2010 at 02:07:27PM -0500, Kenneth Marshall wrote:
>>> Hi Peter,
>>>
>>> All you need to do is define your own sequence with an
>>> increment of 500. Look at:
>>>
>>> http://www.postgresql.org/docs/8.4/static/sql-createsequence.html
>>
>> This is often not enough. For example - I want standard increment of 1,
>> but right now I'm importing 10000 objects, and it would be simpler for
>> me to get 10000 ids. Preferably in one block.
>>
>> This is not achievable now. I know I can 'alter sequence set increment
>> by' - but this will also affect concurrent sessions. which might not be
>> a problem, but it's a side effect that I don't want.
>>
>> +1 for original proposition, would love to get it.
>
> If we do this, I'm inclined to think that the extra argument to
> nextval() should be treated as overriding the base increment rather
> than specifying a multiplier for it.  Other than that nitpick, it
> sounds like a reasonable thing to allow.
>

After giving it some thought, that sounds better. You gain some
functionality that way (temporarily overriding the interval) and lose
none.

Peter

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 14 May 2010 18:11
Peter Crabtree <peter.crabtree(a)gmail.com> writes:
> On Fri, May 14, 2010 at 5:29 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
>> If we do this, I'm inclined to think that the extra argument to
>> nextval() should be treated as overriding the base increment rather
>> than specifying a multiplier for it.  Other than that nitpick, it
>> sounds like a reasonable thing to allow.

> After giving it some thought, that sounds better. You gain some
> functionality that way (temporarily overriding the interval) and lose
> none.

Well, what you lose is the previous assurance that values of nextval()
were always multiples of the increment. I could see that breaking
applications that are using non-unity increments.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2
Prev: recovery consistent != hot standby
Next: Parameter oddness; was HS/SR Assert servercrash