Re: spinlocks on HP-UX

Lists: pgsql-hackers
From: pasman pasmański <pasman(dot)p(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: spinlocks on HP-UX
Date: 2011-08-28 09:41:11
Message-ID: CAOWY8=aCWN+KhXAoSKAmZSo9GQd3JZ1EVBq4FRwU9N7DLP_qgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Pity that this patch works only on hpux :(.

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.

--
------------
pasman


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
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