Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: checkpointer continuous flushing
Date
Msg-id alpine.DEB.2.10.1506220926130.23011@sto
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Hello Jim,

>> The small problem I see is that for a very large setting there could be
>> several seconds or even minutes of sorting, which may or may not be
>> desirable, so having some control on that seems a good idea.
>
> ISTM a more elegant way to handle that would be to start off with a very 
> small number of buffers and sort larger and larger lists while the OS is busy 
> writing/syncing.

You really have to have done a significant part/most/all of sorting before 
starting to write.

>> Another argument is that Tom said he wanted that:-)
>
> Did he elaborate why? I don't see him on this thread (though I don't have all 
> of it).

http://www.postgresql.org/message-id/6599.1409421040@sss.pgh.pa.us

But it has more to do with memory management.

>> In practice the value can be set at a high value so that it is nearly
>> always sorted in one go. Maybe value "0" could be made special and used
>> to trigger this behavior systematically, and be the default.
>
> It'd be nice if it was just self-tuning, with no GUC.

Hmmm. It can easilly be turned into a boolean, but otherwise I have no 
clue about how to decide whether to sort and/or flush.

> It looks like it'd be much better to get this committed without more than we 
> have now than to do without it though...

Yep, I think the figures are definitely encouraging.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: user space function "is_power_user"
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: row_to_array function