On Tue, Feb 28, 2012 at 6:11 PM, Robert Haas wrote:
> On Mon, Feb 27, 2012 at 4:03 AM, Simon Riggs wrote:
>> So please use a scale factor that the hardware can cope with.
>
> OK. I tested this out on Nate Boley's 32-core AMD machine, using
> scale factor 100 and scale factor 300. I initialized i
On Mon, Feb 27, 2012 at 4:03 AM, Simon Riggs wrote:
> So please use a scale factor that the hardware can cope with.
OK. I tested this out on Nate Boley's 32-core AMD machine, using
scale factor 100 and scale factor 300. I initialized it with Simon's
patch, which should have the effect of renderi
On Sun, Feb 26, 2012 at 10:53 PM, Robert Haas wrote:
> On Sat, Feb 25, 2012 at 2:16 PM, Simon Riggs wrote:
>> On Wed, Feb 8, 2012 at 11:26 PM, Robert Haas wrote:
>>> Given that, I obviously cannot test this at this point,
>>
>> Patch with minor corrections attached here for further review.
>
> A
On Sat, Feb 25, 2012 at 2:16 PM, Simon Riggs wrote:
> On Wed, Feb 8, 2012 at 11:26 PM, Robert Haas wrote:
>> Given that, I obviously cannot test this at this point,
>
> Patch with minor corrections attached here for further review.
All right, I will set up some benchmarks with this version, and
On Wed, Feb 8, 2012 at 11:26 PM, Robert Haas wrote:
> Given that, I obviously cannot test this at this point,
Patch with minor corrections attached here for further review.
> but let me go
> ahead and theorize about how well it's likely to work. What Tom
> suggested before (and after some refl
On Fri, Feb 10, 2012 at 7:01 PM, Ants Aasma wrote:
>
> On Feb 9, 2012 1:27 AM, "Robert Haas"
>
>> However, there is a potential fly in the ointment: in other cases in
>> which we've reduced contention at the LWLock layer, we've ended up
>> with very nasty contention at the spinlock layer that can
On Feb 9, 2012 1:27 AM, "Robert Haas"
> However, there is a potential fly in the ointment: in other cases in
> which we've reduced contention at the LWLock layer, we've ended up
> with very nasty contention at the spinlock layer that can sometimes
> eat more CPU time than the LWLock contention did
On Sun, Jan 29, 2012 at 6:04 PM, Simon Riggs wrote:
> On Sun, Jan 29, 2012 at 9:41 PM, Jeff Janes wrote:
>
>> If I cast to a int, then I see advancement:
>
> I'll initialise it as 0, rather than -1 and then we don't have a
> problem in any circumstance.
>
>
>>> I've specifically designed the pgbe
On Mon, Jan 30, 2012 at 12:24 PM, Robert Haas wrote:
> On Fri, Jan 27, 2012 at 8:21 PM, Jeff Janes wrote:
>> On Fri, Jan 27, 2012 at 3:16 PM, Merlin Moncure wrote:
>>> On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes wrote:
Also, I think the general approach is wrong. The only reason to have
>
On Fri, Jan 27, 2012 at 8:21 PM, Jeff Janes wrote:
> On Fri, Jan 27, 2012 at 3:16 PM, Merlin Moncure wrote:
>> On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes wrote:
>>> Also, I think the general approach is wrong. The only reason to have
>>> these pages in shared memory is that we can control acce
On Sun, Jan 29, 2012 at 9:41 PM, Jeff Janes wrote:
> If I cast to a int, then I see advancement:
I'll initialise it as 0, rather than -1 and then we don't have a
problem in any circumstance.
>> I've specifically designed the pgbench changes required to simulate
>> conditions of clog contention
On Sun, Jan 29, 2012 at 1:41 PM, Jeff Janes wrote:
> On Sun, Jan 29, 2012 at 12:18 PM, Simon Riggs wrote:
>> On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
>>> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
Yes, it was. Sorry about that. New version attached, retesting while
On Sun, Jan 29, 2012 at 12:18 PM, Simon Riggs wrote:
> On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
>> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>>>
>>> Yes, it was. Sorry about that. New version attached, retesting while
>>> you read this.
>>
>> In my hands I could never get th
On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>>
>> Yes, it was. Sorry about that. New version attached, retesting while
>> you read this.
>
> In my hands I could never get this patch to do anything. The new
> cache was never used.
>
>
On Sat, Jan 28, 2012 at 1:52 PM, Simon Riggs wrote:
>> Also, I think the general approach is wrong. The only reason to have
>> these pages in shared memory is that we can control access to them to
>> prevent write/write and read/write corruption. Since these pages are
>> never written, they don
On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>>
>> Yes, it was. Sorry about that. New version attached, retesting while
>> you read this.
>
> In my hands I could never get this patch to do anything. The new
> cache was never used.
>
>
On Fri, Jan 27, 2012 at 3:16 PM, Merlin Moncure wrote:
> On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes wrote:
>> Also, I think the general approach is wrong. The only reason to have
>> these pages in shared memory is that we can control access to them to
>> prevent write/write and read/write corru
On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes wrote:
> Also, I think the general approach is wrong. The only reason to have
> these pages in shared memory is that we can control access to them to
> prevent write/write and read/write corruption. Since these pages are
> never written, they don't nee
On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>
> Yes, it was. Sorry about that. New version attached, retesting while
> you read this.
In my hands I could never get this patch to do anything. The new
cache was never used.
I think that that was because RecentXminPageno never budged from -
On Fri, Jan 20, 2012 at 6:44 AM, Simon Riggs wrote:
>
> OT: It would save lots of time if we had 2 things for the CF app:
>
..
> 2. Something that automatically tests patches. If you submit a patch
> we run up a blank VM and run patch applies on all patches. As soon as
> we get a fail, an email go
On Sat, Jan 21, 2012 at 1:57 PM, Robert Haas wrote:
> On Fri, Jan 20, 2012 at 10:44 AM, Robert Haas wrote:
D'oh. You're right. Looks like I accidentally tried to apply this to
the 9.1 sources. Sigh...
>>>
>>> No worries. It's Friday.
>
> Server passed 'make check' with this patch, bu
On Fri, Jan 20, 2012 at 10:44 AM, Robert Haas wrote:
>>> D'oh. You're right. Looks like I accidentally tried to apply this to
>>> the 9.1 sources. Sigh...
>>
>> No worries. It's Friday.
Server passed 'make check' with this patch, but when I tried to fire
it up for some test runs, it fell over
On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas wrote:
> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs wrote:
>> I've taken that idea and used it to build a second Clog cache, known
>> as ClogHistory which allows access to the read-only tail of pages in
>> the clog. Once a page has been written to for
On Fri, Jan 20, 2012 at 10:38 AM, Simon Riggs wrote:
> On Fri, Jan 20, 2012 at 3:32 PM, Robert Haas wrote:
>> On Fri, Jan 20, 2012 at 10:16 AM, Simon Riggs wrote:
>>> On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas wrote:
On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs wrote:
> I've taken th
On Fri, Jan 20, 2012 at 3:32 PM, Robert Haas wrote:
> On Fri, Jan 20, 2012 at 10:16 AM, Simon Riggs wrote:
>> On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas wrote:
>>> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs wrote:
I've taken that idea and used it to build a second Clog cache, known
On Fri, Jan 20, 2012 at 10:16 AM, Simon Riggs wrote:
> On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas wrote:
>> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs wrote:
>>> I've taken that idea and used it to build a second Clog cache, known
>>> as ClogHistory which allows access to the read-only tail o
On Fri, Jan 20, 2012 at 9:44 AM, Simon Riggs wrote:
> On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas wrote:
>> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs wrote:
>>> I've taken that idea and used it to build a second Clog cache, known
>>> as ClogHistory which allows access to the read-only tail of
On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas wrote:
> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs wrote:
>> I've taken that idea and used it to build a second Clog cache, known
>> as ClogHistory which allows access to the read-only tail of pages in
>> the clog. Once a page has been written to for
On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs wrote:
> I've taken that idea and used it to build a second Clog cache, known
> as ClogHistory which allows access to the read-only tail of pages in
> the clog. Once a page has been written to for the last time, it will
> be accessed via the ClogHistory
On Sun, Jan 8, 2012 at 2:25 PM, Simon Riggs wrote:
> I've taken that idea and used it to build a second Clog cache, known
> as ClogHistory which allows access to the read-only tail of pages in
> the clog. Once a page has been written to for the last time, it will
> be accessed via the ClogHistory
Recent results from Robert show clog contention is still an issue.
In various discussions Tom noted that pages prior to RecentXmin are
readonly and we might find a way to make use of that fact in providing
different mechanisms or resources.
I've taken that idea and used it to build a second Clog
31 matches
Mail list logo
