Re: [HACKERS] Could be improved point of UPSERT

2015-07-15 Thread Yourfriend
For the most cases I mentioned, we don't request a strict gapless sequence for the Invoice ID, the essential requirement is unique. We just hope that there is no obviously gap in most situations. >From the test of UPSERT, there are quite a few chances to generate a big gap when UPSERT multi records

Re: [HACKERS] Could be improved point of UPSERT

2015-07-15 Thread Peter Geoghegan
On Wed, Jul 15, 2015 at 12:01 AM, Yourfriend wrote: > for example, SO201507_1001, PO201503_1280, etc. > > As these IDs would be the most important attribute to the business, so, we > hope there is no gap for the IDs. That's a requirement I've heard a number of times before. If you're relying on a

Re: [HACKERS] Could be improved point of UPSERT

2015-07-15 Thread Yourfriend
In my example, I just give each record a different ID to access it efficiently. In our business cases, some times, we also use some prefix letter like 'SO', "PO' combining with the current year, month and then a sequence to make a invoice ID, for example, SO201507_1001, PO201503_1280, etc. As th

Re: [HACKERS] Could be improved point of UPSERT

2015-07-14 Thread Peter Geoghegan
On Tue, Jul 14, 2015 at 11:40 AM, Gianni wrote: > Could there be a version of UPSERT where an update is tried, and if 0 records > are modified, an insert is done? > > Just wondering, I haven't got am use-case for that. I don't mid gaps in > sequences. Perhaps, if you don't mind having a severely

Re: [HACKERS] Could be improved point of UPSERT

2015-07-14 Thread Gianni
On Tuesday 14 July 2015 11:33:34 Peter Geoghegan wrote: > On Sun, Jul 12, 2015 at 4:09 AM, Yourfriend wrote: > > Suggestion: When a conflict was found for UPSERT, don't access the > > sequence, so users can have a reasonable list of ID. > > This is not technically feasible. What if the arbiter i

Re: [HACKERS] Could be improved point of UPSERT

2015-07-14 Thread Peter Geoghegan
On Sun, Jul 12, 2015 at 4:09 AM, Yourfriend wrote: > Suggestion: When a conflict was found for UPSERT, don't access the > sequence, so users can have a reasonable list of ID. This is not technically feasible. What if the arbiter index is a serial PK? The same thing can happen when a transaction

[HACKERS] Could be improved point of UPSERT

2015-07-12 Thread Yourfriend
Hi, Hackers, The feature of UPSERT was my most interested one of 9.5, I really like need it. I have test the different usages for this features like one record input, multi records input, and also more than 10,000 records upserting, all look great, thanks for your work. When I checked my record