Skip site navigation (1) Skip section navigation (2)

Re: Sorting writes during checkpoint

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Sorting writes during checkpoint
Date: 2008-05-04 04:40:19
Message-ID: 4421.1209876019@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
>> If shared_buffers(=NBuffers) is set to something big, this could give some 
>> memory churn.  And I think it's a bad idea to allocate something this 
>> large at checkpoint time, because what happens if that fails?  Really not 
>> the time you want to discover there's no RAM left.

> Hmm, but I think we need to copy buffer tags into bgwriter's local memory
> in order to avoid locking taga many times in the sorting.

I updated this patch to permanently allocate the working array as Greg
suggests, and to fix a bunch of commenting issues (attached).

However, I am completely unable to measure any performance improvement
from it.  Given the possible risk of out-of-memory failures, I think the
patch should not be applied without some direct proof of performance
benefits, and I don't see any.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Euler Taveira de OliveiraDate: 2008-05-04 05:21:41
Subject: Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Previous:From: Tom LaneDate: 2008-05-04 00:55:31
Subject: Re: [HACKERS] Multiline privileges in \z

pgsql-patches by date

Next:From: Euler Taveira de OliveiraDate: 2008-05-04 05:21:41
Subject: Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Previous:From: Tom LaneDate: 2008-05-04 00:55:31
Subject: Re: [HACKERS] Multiline privileges in \z

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group