|From:||Nico Williams <nico(at)cryptonector(dot)com>|
|To:||"Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>|
|Cc:||PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Surafel Temesgen <surafel3000(at)gmail(dot)com>|
|Subject:||Re: ON CONFLICT DO NOTHING on pg_dump|
|Views:||Raw Message | Whole Thread | Download mbox|
On Fri, Jun 15, 2018 at 02:20:21AM +0000, Ideriha, Takeshi wrote:
> >From: Nico Williams [mailto:nico(at)cryptonector(dot)com]
> >On Tue, Jun 12, 2018 at 09:05:23AM +0000, Ideriha, Takeshi wrote:
> >> Only the difference of data can be restored.
> >But that's additive-only. Only missing rows are restored this way, and differences are
> >not addressed.
> >If you want restore to restore data properly and concurrently (as opposed to renaming
> >a new database into place or whatever) then you'd want a) MERGE, b) dump to
> >generate MERGE statements. A concurrent data restore operation would be rather
> I agree with you though supporting MERGE or ON-CONFLICT-DO-UPDATE seems hard work.
> Only ON-CONCLICT-DO-NOTHING use case may be narrow.
Is it narrow, or is it just easy enough to add quickly?
And by the way, you don't need MERGE. You can just generate INSERT/
UPDATE/DELETE statements -- MERGE is mainly an optimization on that, and
could wait until PG has a MERGE.
|Next Message||Andres Freund||2018-06-18 15:57:19||Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.|
|Previous Message||Jesper Pedersen||2018-06-18 15:25:39||Index Skip Scan|