On Tue, Oct 15, 2013 at 5:15 AM, Robert Haas <robertmh...@gmail.com> wrote: > Well, the SQL standard way of doing this type of operation is MERGE. > The alternative we know exists in other databases is REPLACE; there's > also INSERT .. ON DUPLICATE KEY update. In all of those cases, > whatever weirdness exists around MVCC is confined to that one command. > I tend to think we should do similarly, with the goal that > HeapTupleSatisfiesMVCC need not change at all.
I don't think that it's very pragmatic to define success in terms of not modifying a single visibility function. I feel it would be more useful to define it as providing acceptable, non-surprising semantics, while not regressing performance in other areas. The fact remains that you're going to have a create a new snapshot type even for this special case, so I don't see any win as regards managing invasiveness here. Quite the contrary, in fact. > I don't have the only vote here, of course, but my feeling is that > that's more likely to be a good route. Naturally we all want MERGE. It seems self-defeating to insist on something significantly harder that there is significant less demand for, though. I thought that there was at least informal agreement that this sort of approach was preferable to MERGE in its full generality, based on feedback at the 2012 developer meeting. I really don't think that what I've done here is any worse than INSERT...ON DUPLICATE KEY UPDATE in any of the areas you express concern about here. REPLACE has some serious problems, and I just don't see it as a viable alternative at all - just ask any MySQL user. MERGE is of course more flexible to what I have here in some ways, but actually less flexible in other ways. I think that the real point of MERGE is that it's defined in a way that serves data warehousing use cases very well: the semantics constrain things such that the executor only has to execute a single ModifyTable node that does inserts, updates and deletes in a single scan. That's great, but what if it's useful to do that CRUD (yes, this can include selects) to entirely different tables? Or what if the relevant DML will only come in a later statement in the same transaction? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
