From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Date: | 2012-03-06 19:34:24 |
Message-ID: | 4F5666C0.5030304@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06.03.2012 17:12, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> On 06.03.2012 14:52, Fujii Masao wrote:
>>> This also strikes me that the usage of the spinlock insertpos_lck might
>>> not be OK in ReserveXLogInsertLocation() because a few dozen instructions
>>> can be performed while holding the spinlock....
>
>> I admit that block is longer than any of our existing spinlock blocks.
>> However, it's important for performance. I tried using a lwlock earlier,
>> and that negated the gains. So if that's a serious objection, then let's
>> resolve that now before I spend any more time on other aspects of the
>> patch. Any ideas how to make that block shorter?
>
> How long is the current locked code exactly --- does it contain a loop?
Perhaps best if you take a look for yourself, the function is called
ReserveXLogInsertLocation() in patch. It calls a helper function called
AdvanceXLogRecPtrToNextPage(ptr), which is small and could be inlined.
It does contain one loop, which iterates once for every WAL page the
record crosses.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2012-03-06 19:38:21 | Re: [9.2] Confusion over CacheRegisterSyscacheCallback |
Previous Message | Bruce Momjian | 2012-03-06 19:27:35 | Re: Checksums, state of play |