Re: [HACKERS] HaveNFreeProcs() iterates through entire freeProcs list
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 Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HaveNFreeProcs() iterates through entire freeProcs list
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" part of the while condition. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] HaveNFreeProcs() iterates through entire freeProcs list
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 return as soon as that's true, instead of waiting until the end?
BTW, the comment certainly doesn't seem accurate for the current code,
since performance will be determined entirely by the number of procs on
freeProcs...
/*
* Check whether there are at least N free PGPROC objects.
*
* Note: this is designed on the assumption that N will generally be small.
*/
bool
HaveNFreeProcs(int n)
{
PGPROC *proc;
SpinLockAcquire(ProcStructLock);
proc = ProcGlobal->freeProcs;
while (n > 0 && proc != NULL)
{
proc = (PGPROC *) proc->links.next;
n--;
}
SpinLockRelease(ProcStructLock);
return (n <= 0);
}
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HaveNFreeProcs ?
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 enforced a sane > upper limit on superuser_reserved_connections. I'm thinking somewhere > around 10. > > Any thoughts about that? Maybe a warning in the docs and the sample/default config file would be better. It seems silly to limit this just because it might cause a performance problem (this is just a performance issue, right?) -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HaveNFreeProcs ?
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. I'm thinking somewhere around 10. Any thoughts about that? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] HaveNFreeProcs ?
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 confusing it with CountActiveBackends. But the other point stands. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] HaveNFreeProcs ?
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 numBackends includes prepared transactions that's no longer a useful test. I think that the existing coding is OK, 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. 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. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] HaveNFreeProcs ?
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 () Jason Tesser: You might not have understood me or I am not understanding you. Paul Thomas: It feels like we're 2 people divided by a common language... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
