| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | hlinnaka <hlinnaka(at)iki(dot)fi> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
| Date: | 2015-03-31 13:26:39 |
| Message-ID: | CAM3SWZSLBBmuWj0g9fh7mfBhAU2xfCoH-EVMgwxcLSFwjisQQg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 31, 2015 at 1:09 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I'm pretty sceptical of that. ISTM you'll need to do modify the page twice
> for each insertion, first to insert the promise tuple, and then to turn the
> promise tuple into a real tuple. And WAL-log both updates. That's going to
> hurt performance.
Andres' wish to do things that way is at least partially motivated by
having logical decoding just work. The co-ordination I'm currently
doing across changes within transaction reassembly is pretty ugly.
Andres has strongly suggested that it's broken, too, since a snapshot
change could occur between a speculative insertion and its super
deletion within transaction resassembly, thus invalidating the
assumption that the next change not being a super deletion means there
is no such super deletion change (i.e. the insert should be treated as
"real").
Anyway, if we don't do this, we'll need to make sure my changes to
transaction reassembly are sound. Hopefully that's an easy fix.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2015-03-31 13:29:29 | Re: WIP: SCRAM authentication |
| Previous Message | Heikki Linnakangas | 2015-03-31 13:19:58 | Re: WAL format changes break the suppression of do-nothing checkpoints. |