Re: checkpointer continuous flushing

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: checkpointer continuous flushing
Date: 2015-09-07 07:32:10
Message-ID: alpine.DEB.2.10.1509070912460.32076@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Amit,

>> It'd not really simplify things, but it'd keep it local.
> How about using the value of guc (checkpoint_flush_to_disk) and
> AmCheckpointerProcess to identify whether to do async flush in
> FileWrite?

ISTM that what you suggest would just replace the added function arguments
with global variables to communicate and keep the necessary data for
managing the asynchronous flushing, which is called per tablespace
(1) on file changes (2) when the checkpointer is going to sleep.

Although it can be done obviously, I prefer to have functions arguments
rather than global variables, on principle.

Also, because of (2) and of the dependency on the number of tablespaces
being flushed, the flushing stuff cannot be fully hidden from the
checkpointer anyway.

Also I think that probably the bgwriter should do something similar, so
function parameters would be useful to drive flushing from it, rather than
adding yet another set of global variables, or share the same variables
for somehow different purposes.

So having these added parameters look reasonable to me.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-09-07 08:05:50 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Atsushi Yoshida 2015-09-07 05:49:11 Re: Too many duplicated condition query return wrong value