Re: tackling full page writes
От | Robert Haas |
---|---|
Тема | Re: tackling full page writes |
Дата | |
Msg-id | BANLkTi=i4D6KJgPbfDO-naijYSNoPzRgbw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: tackling full page writes (Greg Smith <greg@2ndQuadrant.com>) |
Ответы |
Re: tackling full page writes
|
Список | pgsql-hackers |
On Wed, May 25, 2011 at 1:06 PM, Greg Smith <greg@2ndquadrant.com> wrote: > On 05/24/2011 04:34 PM, Robert Haas wrote: >> >> we could name this feature "partial full page writes" and enable it >> either with a setting of full_page_writes=partial > > +1 to overloading the initial name, but only if the parameter is named > 'maybe', 'sometimes', or 'perhaps'. Perfect! > I've been looking into a similar refactoring of the names here, where we > bundle all of these speed over safety things (fsync, full_page_writes, etc.) > into one control so they're easier to turn off at once. Not sure if it > should be named "web_scale" or "do_you_feel_lucky_punk". Actually, I suggested that same idea to you, or someone, a while back, only I was serious. crash_safety=off. I never got around to fleshing out the details, though. >> 3. Going a bit further, Greg proposed the idea of ripping out our >> current WAL infrastructure altogether and instead just having one WAL >> record that says "these byte ranges on this page changed to have these >> new contents". > > The main thing that makes this idea particularly interesting to me, over the > other two, is that it might translate well into the idea of using > sync_file_range to aim for a finer fsync call on Linux than is currently > possible. Hmm, maybe. But it's possible that the dirty blocks are the first and last ones in the file. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: