Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

Greg Smith <greg@2ndquadrant.com>

From: Greg Smith <greg@2ndquadrant.com>
To: David Fetter <david@fetter.org>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>, Boxuan Zhai <bxzhai2010@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-01-05T02:27:10Z
Lists: pgsql-hackers
David Fetter wrote:
> How about implementing an UPSERT command as "take the lock, do the
> merge?"  That way, we'd have both the simplicity for the simpler cases
> and a way to relax consistency guarantees for those who would like to
> do so.
>   

Main argument against is that path leads to a permanent non-standard 
wart to support forever, just to work around what should be a short-term 
problem.  And I'm not sure whether reducing the goals to only this 
actually improves the ability to ship something in the near term too 
much.  Many of the hard problems people are bothered by don't go away, 
it just makes deciding which side of the speed/complexity trade-off 
you're more interested in becomes more obvious.  What I've been 
advocating is making that decision go away altogether by only worrying 
about the simple to use and slow path for now, but that's a highly 
debatable viewpoint I appreciate the resistence to, if it's possible to 
do at all.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books