On Tue, 18 Apr 2023 at 11:53, John Howroyd wrote:
>
> Sorry, I may have jumped to a conclusion that's not quite correct.
Not at all, thanks for moving this along
> On Mon, 17 Apr 2023 at 23:58, Federico wrote:
>>
>> On Tue, 18 Apr 2023 at 00:21
put order
> by inserting a counter.
I didn't mean to suggest any particular order should be kept by insert
or by returning. I was merely commenting on the David G. Johnston
reply
I suppose breaking the restriction that only columns present on
the insertion-table can be returned is a possible option that also
solves another infrequent request.
> Apologies, if I have misunderstood or invented something that's not possible!
Thanks for the recap. I'm hoping this can become a proposal.
Best,
Federico
On Sat, 15 Apr 2023 at 15:40, Tom Lane wrote:
>
> Federico writes:
> > I think the tuple order would not be connected to the values, but be
> > determined by the input order of the rows in the insert. So when using
> > INSERT ... SELECT the tuple_order value would be dete
On Sat, 15 Apr 2023 at 05:17, 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
be tuple_order 1, entry (4, 5, 6) would be tuple order 2, etc.
This would allow easy reordering of the RETURNING clause, either
client side or moving the INSERT into a CTE and ordering the outside
select. I also don't think it would have any impact on parallel
processing of the INSERT, since RETURNING could output rows in any
arbitrary order.
Best,
Federico
On Wed, 12 Apr 2023 at 23:49, Adrian Klaver wrote:
>
> On 4/12/23 2:35 PM, Kirk Wolak wrote:
> > On Tue, Apr 11, 2023 at 4:38 PM Federico
> >
> > A couple of comments. For the more generic, I prefer RETURNING *
> > you get back all the columns for matching. To m
On Wed, 12 Apr 2023 at 11:46, Thorsten Glaser wrote:
>
> On Tue, 11 Apr 2023, Federico wrote:
>
> >My understanding was that they are generated in select order
>
> But are they? (I don’t know, but I’d not assume that.)
That's kind of the point for this question, to
similar, that's something that is done,
> > but if there are no unique columns in the value no match can be done
> > reliably with the source data, since sqlalchemy is a library that
> > allows arbitrary schemas to be generated.
> >
> > Thanks for the reply,
> >Federico
> So
On Tue, 11 Apr 2023 at 23:44, Thorsten Glaser wrote:
>
> On Tue, 11 Apr 2023, Federico wrote:
>
> >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 g
On Tue, 11 Apr 2023 at 23:31, Rob Sargent wrote:
>
> On 4/11/23 14:37, Federico wrote:
> >
> > The problem here is not having the auto increment id in a particular
> > order, is that there
> > is apparently no correlation with the position of an element in the
>
On Tue, 11 Apr 2023 at 23:22, Thorsten Glaser wrote:
>
> On Tue, 11 Apr 2023, Federico wrote:
>
> >Of course sorting the returned ids is only viable when using a serial
>
> Yes, which is why I pointed out it doesn’t have to be.
>
> >or identity column, that'
On Tue, 11 Apr 2023 at 22:59, Thorsten Glaser wrote:
>
> On Tue, 11 Apr 2023, Federico wrote:
>
> >The problem here is not having the auto increment id in a particular
>
> The id might not even be auto-increment but UUID or something…
> (I am surprised you would even try
mple is very easy, but it's hard to generalize when
inserting multiple columns
with possible complex values in them, since it would mean matching on
possibly large json values,
arrays, etc. So definitely not ideal
Thanks,
Federico
On Tue, 11 Apr 2023 at 22:06, Adrian Klaver wrote:
>
> On
case)
Sorry for the long email,
Thanks
Federico
I've changed the code to use order by in the aggregate and it seems
there are no noticeable changes in the query performance.
Thanks for the help.
Best,
Federico Caselli
On Sun, 25 Sept 2022 at 00:30, Federico wrote:
>
> Understood, thanks for the explanation.
> I'll work on
nize when the input is already correctly sorted
> for an aggregate, so it should get better in PG 16 or so.
Nice to know, hopefully it's too bad for this use case
Thanks, Federico Caselli
On Sun, 25 Sept 2022 at 00:20, Tom Lane wrote:
>
> Federico writes:
> > A basic example of the t
ere if they may prove useful.
Thank you
Federico
17 matches
Mail list logo
