From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | Pantelis Theodosiou <ypercube(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Feature suggestion: ON CONFLICT DO NOTHING RETURNING which returns existing row data |
Date: | 2016-10-06 07:49:39 |
Message-ID: | 25247983-2BB2-4B2F-86E7-C9F313278F81@tomd.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 5 Oct 2016, at 8:11 PM, Pantelis Theodosiou <ypercube(at)gmail(dot)com> wrote:
>
> This can be solved by chaining modifying CTEs.
>
> Something like this (not tested) that can work with multiple rows inserted:
Thanks for the suggestion, but it was actually slower than our current implementation, I believe due to always looking up t1’s id in that join rather than only doing it when we didn’t get an id back from the insert. My hope with this feature suggestion / request was that we wouldn’t have to do that subsequent lookup at all, as pg would just give it back to us.
Maybe it would be a win if we were inserting multiple rows, but this code is actually in a trigger on a dummy table that we COPY data in to - thus it can’t be rewritten as a rule or a multi-row insert like that.
Thanks
Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2016-10-06 08:04:07 | Re: Transactions involving multiple postgres foreign servers |
Previous Message | Amit Langote | 2016-10-06 07:14:04 | Re: Declarative partitioning - another take |