| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Date: | 2012-06-01 00:45:40 |
| Message-ID: | CAMkU=1yqoxWJODrc3GWdZt8mUz+PFmvmFjE2U+0ksrMM8dRZBw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 31, 2012 at 11:50 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> This test case is unusual because it hits a whole series of buffers
> very hard. However, there are other cases where this happens on a
> single buffer that is just very, very hot, like the root block of a
> btree index, where the pin/unpin overhead hurts us.
I think that very very hot page is also the problem here, not a whole
sequence of hot pages. Most of his buffer content sh lwlocks are on
just two buffers, and most of his blocked buffer mapping lwlocks on
are on just two partitions. So I am guessing that almost all of his
spin-lock contention from Pin and Unpin are also coming from those
same two buffers. Why there are two buffers when there is only one
index root block involved, I don't know.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2012-06-01 00:58:11 | Re: slow dropping of tables, DropRelFileNodeBuffers, tas |
| Previous Message | Jeff Janes | 2012-06-01 00:27:41 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |