From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-06-22 07:29:40 |
Message-ID: | alpine.DEB.2.10.1506220926130.23011@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-06-22 07:46:15 | Re: proposal: row_to_array function |
Previous Message | Pavel Stehule | 2015-06-22 06:51:34 | user space function "is_power_user" |