Skip site navigation (1) Skip section navigation (2)

Re: spinlocks on HP-UX

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: pasman pasmański <pasman(dot)p(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: spinlocks on HP-UX
Date: 2011-08-29 00:01:56
Message-ID: CA+Tgmob62m+H2XauArLiKq0GyN+j3Bayhak4tmAH-S7yYbTojQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2011/8/28 pasman pasmański <pasman(dot)p(at)gmail(dot)com>:
> Pity that this patch works only on hpux :(.

Well, not really.  x86 is already well-behaved.  On a 32-core x86 box
running Linux, performs seems to plateau and level off, and then fall
off gradually.  But on ia64, performance just collapses after about 24
cores.  The fact that we don't have that problem everywhere is a good
thing, not a bad thing...

> But i have an idea: maybe when executor stop at locked row, it should
> process next row instead of wait.
>
> Of course if query not contain "order by" or windowing functions.

That wouldn't really help, first of all because you'd then have to
remember to go back to that row (and chances are it would still be
contended then), and second because these aren't row-level locks
anyway.  They're locks on various global data structures, such as the
ProcArray.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: YAMAMOTO TakashiDate: 2011-08-29 00:28:34
Subject: Re: tab stop in README
Previous:From: Tom LaneDate: 2011-08-29 00:00:05
Subject: Re: spinlocks on HP-UX

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group