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