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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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