Re: checkpointer continuous flushing - V18

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: checkpointer continuous flushing - V18
Дата
Msg-id 20160219202001.5knghmdwdsazurhj@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: checkpointer continuous flushing - V16  (Andres Freund <andres@anarazel.de>)
Ответы Re: checkpointer continuous flushing - V18  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: checkpointer continuous flushing - V18  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: checkpointer continuous flushing - V18  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
On 2016-02-04 16:54:58 +0100, Andres Freund wrote:
> Hi,
>
> Fabien asked me to post a new version of the checkpoint flushing patch
> series. While this isn't entirely ready for commit, I think we're
> getting closer.
>
> I don't want to post a full series right now, but my working state is
> available on
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/checkpoint-flush
> git://git.postgresql.org/git/users/andresfreund/postgres.git checkpoint-flush

I've updated the git tree.

Here's the next two (the most important) patches of the series:
0001: Allow to trigger kernel writeback after a configurable number of writes.
0002: Checkpoint sorting and balancing.

For 0001 I've recently changed:
* Don't schedule writeback after smgrextend() - that defeats linux
  delayed allocation mechanism, increasing fragmentation noticeably.
* Add docs for the new GUC variables
* comment polishing
* BackendWritebackContext now isn't dynamically allocated anymore


I think this patch primarily needs:
* review of the docs, not sure if they're easy enough to
  understand. Some language polishing might also be needed.
* review of the writeback API, combined with the smgr/md.c changes.
* Currently *_flush_after can be set to a nonzero value, even if there's
  no support for flushing on that platform. Imo that's ok, but perhaps
  other people's opinion differ.


For 0002 I've recently changed:
* Removed the sort timing information, we've proven sufficiently that
  it doesn't take a lot of time.
* Minor comment polishing.

I think this patch primarily needs:
* Benchmarking on FreeBSD/OSX to see whether we should enable the
  mmap()/msync(MS_ASYNC) method by default. Unless somebody does so, I'm
  inclined to leave it off till then.


Regards,

Andres

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: FDW: should GetFdwRoutine be called when drop table?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_ctl promote wait