Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
От | Marko Tiikkaja |
---|---|
Тема | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
Дата | |
Msg-id | 4D1C7132.60804@cs.helsinki.fi обсуждение исходный текст |
Ответ на | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Re: new patch of MERGE (merge_204) & a question about
duplicated ctid
|
Список | pgsql-hackers |
On 2010-12-30 9:02 AM +0200, Greg Smith wrote: > Marko Tiikkaja wrote: >> I have no idea why it worked in the past, but the patch was never >> designed to work for UPSERT. This has been discussed in the past and >> some people thought that that's not a huge deal. > > It takes an excessively large lock when doing UPSERT, which means its > performance under a heavy concurrent load can't be good. The idea is > that if the syntax and general implementation issues can get sorted out, > fixing the locking can be a separate performance improvement to be > implemented later. Using MERGE for UPSERT is the #1 use case for this > feature by a gigantic margin. If that doesn't do what's expected, the > whole implementation doesn't provide the community anything really worth > talking about. That's why I keep hammering on this particular area in > all my testing. I'm confused. Are you saying that the patch is supposed to lock the table against concurrent INSERT/UPDATE/DELETE/MERGE? Because I don't see it in the patch, and the symptoms you're having are a clear indication of the fact that it's not happening. I also seem to recall that people thought locking the table would be excessive. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: