On Tue, Oct 15, 2013 at 11:23 AM, Josh Berkus <j...@agliodbs.com> wrote: > (although, AFAICT it doesn't allow for the implementation of one of my > personal desires, which is UPDATE ... ON NOT FOUND INSERT, for cases > where updates are expected to occur 95% of the time, but that's another > topic. Unless "rejects" for an Update could be the leftover rows, but > then we're getting into full MERGE.).
This isn't really all that inefficient for that case. Certainly, the balance in cost between mostly-insert cases and mostly-update cases is a strength of my basic approach over others. > Does this version make a distinction between PRIMARY KEY constraints and > UNIQUE indexes? If not, how does it pick among keys? If so, what about > tables with no PRIMARY KEY for various reasons (like unique GiST indexes?) We thought about prioritizing where to look (mostly as a performance optimization), but right now no. It works with amcanunique methods, which in practice means btrees. There is no such thing as a GiST unique index, so I guess you're referring to an exclusion constraint on an equality operator. That doesn't work with this, but why would you want it to? As for generalizing this to work with exclusion constraints, which I guess you might have also meant, that's a much more difficult and much less compelling proposition, in my opinion. -- 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
