Re: [HACKERS] HaveNFreeProcs() iterates through entire freeProcs list

2016-12-02 Thread Jim Nasby
On 12/2/16 12:52 PM, Tom Lane wrote: I think you misread it. Note the "n > 0" part of the while condition. *facepalm* Sorry for the noise... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in

Re: [HACKERS] HaveNFreeProcs() iterates through entire freeProcs list

2016-12-02 Thread Tom Lane
Jim Nasby writes: > Current HaveNFreeProcs() iterates through the entire freeProcs list > (while holding ProcStructLock) just to determine if there's a small > number (superuser_reserved_connections) of free slots available. I think you misread it. Note the "n > 0"

[HACKERS] HaveNFreeProcs() iterates through entire freeProcs list

2016-12-02 Thread Jim Nasby
Current HaveNFreeProcs() iterates through the entire freeProcs list (while holding ProcStructLock) just to determine if there's a small number (superuser_reserved_connections) of free slots available. For the common case, presumably it'd be faster to put the n<=0 test inside the loop and

Re: [HACKERS] HaveNFreeProcs ?

2005-06-24 Thread Jim C. Nasby
On Thu, Jun 23, 2005 at 12:44:25AM -0400, Tom Lane wrote: I wrote: ... because it's written to not loop more than superuser_reserved_connections times, and it's hard to imagine anyone would set that to more than half a dozen or so. We could help keep people on the correct path if guc.c

[HACKERS] HaveNFreeProcs ?

2005-06-22 Thread Alvaro Herrera
Hackers, I just noticed the HaveNFreeProcs routine is coded as a loop around the ProcGlobal struct members. I wonder if it's possible to use a simple check in procArray-numBackends against procArray-maxBackends instead? -- Alvaro Herrera (alvherre[a]surnet.cl) Jason Tesser: You might not have

Re: [HACKERS] HaveNFreeProcs ?

2005-06-22 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: I just noticed the HaveNFreeProcs routine is coded as a loop around the ProcGlobal struct members. I wonder if it's possible to use a simple check in procArray-numBackends against procArray-maxBackends instead? It used to look like that, but now that

Re: [HACKERS] HaveNFreeProcs ?

2005-06-22 Thread Tom Lane
I wrote: Also, that routine will disappear entirely if we agree to remove commit_siblings (see nearby thread), so right at the moment I'm not very concerned about improving it. If it is still there forty-eight hours from now, let's talk about it then. Oh, never mind that, I was momentarily

Re: [HACKERS] HaveNFreeProcs ?

2005-06-22 Thread Tom Lane
I wrote: ... because it's written to not loop more than superuser_reserved_connections times, and it's hard to imagine anyone would set that to more than half a dozen or so. We could help keep people on the correct path if guc.c enforced a sane upper limit on superuser_reserved_connections.