Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-27 Thread Christophe Pettus
On Oct 27, 2009, at 4:37 PM, Merlin Moncure wrote: 'as is', advisory locks is a fantastic feature that can be used for signaling, mutexing, etc that are relatively difficult things to do in the transactional world of sql. My main gripe is that the 'shared id' method for doing record pessimistic

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-27 Thread Merlin Moncure
On Tue, Oct 27, 2009 at 12:43 PM, Josh Berkus wrote: > Merlin, > >> Why even bother with a hash function when you can just have multiple >> table pull from a shared sequence?  AFAICT, this solves the OP's >> problem with no downsides (I used the approach with excellent results >> in a ported cobol

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-27 Thread Josh Berkus
Merlin, > Why even bother with a hash function when you can just have multiple > table pull from a shared sequence? AFAICT, this solves the OP's > problem with no downsides (I used the approach with excellent results > in a ported cobol app which had pessimistic locking requirement). Well, if yo

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-27 Thread Merlin Moncure
On Mon, Oct 26, 2009 at 4:30 PM, Josh Berkus wrote: > >> Why aren't you satisfied with hashtext('foo') ? > > Collisions, mostly. Why even bother with a hash function when you can just have multiple table pull from a shared sequence? AFAICT, this solves the OP's problem with no downsides (I used

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-27 Thread Kenneth Marshall
On Mon, Oct 26, 2009 at 06:35:13PM -0700, Christophe Pettus wrote: > > On Oct 26, 2009, at 5:24 PM, Itagaki Takahiro wrote: > >> Hmmm, hashtext() returns int32. , >> Can you reduce the collision issue if we had hashtext64()? > > That would certainly reduce the chance of a collison considerably, ass

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Christophe Pettus
On Oct 26, 2009, at 5:24 PM, Itagaki Takahiro wrote: Hmmm, hashtext() returns int32. , Can you reduce the collision issue if we had hashtext64()? That would certainly reduce the chance of a collison considerably, assuming the right algorithm. -- -- Christophe Pettus x...@thebuild.com

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Itagaki Takahiro
Josh Berkus wrote: > > Why aren't you satisfied with hashtext('foo') ? > > Collisions, mostly. Hmmm, hashtext() returns int32. , Can you reduce the collision issue if we had hashtext64()? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Josh Berkus
> Why aren't you satisfied with hashtext('foo') ? Collisions, mostly. > The restriction comes from LOCKTAG struct, in which > we can use only 3 * uint32 and 1 * uint16 for lock descriptor. Yeah, that's a pretty hard limit. NM, we'll have to figure out some way around it. --Josh Berkus -- S

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Heikki Linnakangas
Alvaro Herrera wrote: > Christophe Pettus wrote: > >> API Changes: >> >> Overloading the various advisory lock functions to take a suitable >> string type (varchar(64)?) in addition to the bigint / 2 x int >> variations. As with the bigint / 2 x int forms, this string >> namespace would be disjoi

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Tom Lane
Christophe Pettus writes: > I'd like to propose a potential patch, and wanted to get preliminary > feedback on it before I started looking into the design. > Summary:Add a string key space to the advisory lock functionality. Your chances of making the LOCKTAG struct bigger for this are non

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Merlin Moncure
On Mon, Oct 26, 2009 at 1:54 AM, Christophe Pettus wrote: > Greetings, > > I'd like to propose a potential patch, and wanted to get preliminary > feedback on it before I started looking into the design. > > Summary:    Add a string key space to the advisory lock functionality. > > Rationale: > > R

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Alvaro Herrera
Christophe Pettus wrote: > API Changes: > > Overloading the various advisory lock functions to take a suitable > string type (varchar(64)?) in addition to the bigint / 2 x int > variations. As with the bigint / 2 x int forms, this string > namespace would be disjoint from the other key spaces.

Re: [HACKERS] Proposal: String key space for advisory locks

2009-10-26 Thread Itagaki Takahiro
Christophe Pettus wrote: > Summary:Add a string key space to the advisory lock functionality. Why aren't you satisfied with hashtext('foo') ? The restriction comes from LOCKTAG struct, in which we can use only 3 * uint32 and 1 * uint16 for lock descriptor. Regards, --- ITAGAKI Takahiro NT

[HACKERS] Proposal: String key space for advisory locks

2009-10-25 Thread Christophe Pettus
Greetings, I'd like to propose a potential patch, and wanted to get preliminary feedback on it before I started looking into the design. Summary:Add a string key space to the advisory lock functionality. Rationale: Right now, the key spaces (the range of unique values that can be used