Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Thu, Sep 26, 2013 at 07:43:15AM -0400, Bruce Momjian wrote:
> On Wed, Sep 25, 2013 at 08:48:11PM -0700, Peter Geoghegan wrote:
> > On Wed, Sep 25, 2013 at 8:19 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > This thread had a lot of discussion about bloating. I wonder, does the
> > > code check to see if there is a matching row _before_ adding any data?
> >
> > That's pretty much what the patch does.
>
> So, I guess my question is if we are only bloating on a contended
> operation, do we expect that to happen so much that bloat is a problem?
>
> I think the big objection to the patch is the additional code complexity
> and the potential to slow down other sessions. If it is only bloating
> on a contended operation, are these two downsides worth avoiding the
> bloat?

Also, this isn't like the case where we are incrementing sequences --- I
am unclear what workload is going to cause a lot of contention. If two
sessions try to insert the same key, there will be bloat, but later
upsert operations will already see the insert and not cause any bloat.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +