On Fri, Apr 14, 2023, at 11:17 PM, Tom Lane wrote:
> Federico writes:
>> Would something like what was proposed by Mike Bayer be considered?
>
>>> A new token called "tuple_order" or something
>>>
>>> INSERT INTO table (a, b, c) VALUES ((
he RETURNING in any order and do the final sort of "id" client side;
we are only sending out batches of a few thousand rows at a time.The
"order" is not actually what's important, it's that we can relate server
generated values to each tuple inside VALUES.
>
gt; see what query explains can allude to. Does anyone have a test case where
>> the order is not preserved?
>>
>> Might I also point out that if the implementation of parallel inserts does
>> create a bar then doing so may end up with the programmatic interfaces (such
back to having insert of 1000 rows be 3-5x slower for
all tables w server generated primary keys which is what statement at a time
gets us. Surrogate integer Pks w sequence or identity is the big case.
On Wed, Apr 12, 2023, at 8:58 PM, Thorsten Glaser wrote:
> On Wed, 12 Apr 2023, Mike Bayer wr
On Wed, Apr 12, 2023, at 6:24 PM, Thorsten Glaser wrote:
> On Wed, 12 Apr 2023, Kirk Wolak wrote:
>
> >The solution exists. Pre-fetch the IDs, assign them and insert them with
> >the IDs. Then you have 100% control.
> >SELECT NEXTVAL('tbl_seq') from GENERATE_SERIES(1, );
>
> This would be a
I'm not getting every reply in the list but I want to point this out from the
archive version of this thread:
> > I was under the impression that when using INSERT SELECT ORDER BY the
> > sequence
> > ids were generated using the select order.
> But someone said that’s not guaranteed,
On Tue, Apr 11, 2023, at 4:22 PM, Tom Lane wrote:
> Federico writes:
> > Searching the archive seems that a using the INSERT SELECT ORDER BY
> > form should be a better solution,
> > so the above insert should be rewritten as
>
> > INSERT INTO t(data)
> > SELECT data FROM (VALUES ('a',
