Re: INSERT WHERE NOT EXISTS

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mike Mascari <mascarm(at)mascari(dot)com>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Ian Barwick <barwick(at)gmx(dot)net>, techlist(at)voyager(dot)phys(dot)utk(dot)edu, pgsql-general(at)postgresql(dot)org
Subject: Re: INSERT WHERE NOT EXISTS
Date: 2003-06-27 13:37:00
Message-ID: 5.2.1.1.1.20030627212624.02fa04c8@mbox.jaring.my
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

At 10:05 AM 6/26/2003 -0400, Tom Lane wrote:

>Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> writes:
> > (Related: I also suggested arbitrary user locks years back, but I wasn't
> > able to implement them.)
>
>Don't we have 'em already? See contrib/userlock/.

Kinda.

The one I was thinking of was locking on an arbitrary string - which would
allows application level insert lock of even finer granularity amongst
other things.

You can then actually lock on stuff you are trying to insert and it won't
block other unrelated inserts.

Now that I think of it, one could achieve something possibly close enough
with the existing userlock, just lock on the first/last/hash 32 bits of the
data you want to insert. Sure some inserts will clash, but it's still
better than blocking all other inserts. The 16 bit group could be for the
tables.

D'oh. Sure took me a long while to realize this... <sheepish grin>.

Link.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message The Hermit Hacker 2003-06-27 13:39:27 Re: developers.postgresql.org
Previous Message Doug McNaught 2003-06-27 12:43:13 Re: Vacuum (table performance)