Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Date
Msg-id 4D23D6FE.2050004@2ndquadrant.com
Whole thread Raw
In response to Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid  (David Fetter <david@fetter.org>)
Responses Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid  (David Fetter <david@fetter.org>)
List 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



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Next
From: Robert Haas
Date:
Subject: making an unlogged table logged