From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-06-27 06:58:17 |
Message-ID: | alpine.DEB.2.10.1506270803150.32741@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Attached is an updated version of the patch which turns the sort option into
> a boolean, and also include the sort time in the checkpoint log.
>
> There is still an open question about whether the sorting buffer allocation
> is lost on some signals and should be reallocated in such event.
In such case, probably the allocation should be managed from
CheckpointerMain, and the lazy allocation could remain for other callers
(I guess just "initdb").
More open questions:
- best name for the flush option (checkpoint_flush_to_disk,
checkpoint_flush_on_write, checkpoint_flush, ...)
- best name for the sort option (checkpoint_sort,
checkpoint_sort_buffers, checkpoint_sort_ios, ...)
Other nice-to-have inputs:
- tests on a non-linux system with posix_fadvise
(FreeBSD? others?)
- tests on a large dedicated box
Attached are some scripts to help with testing, if someone's feels like
that:
- cp_test.sh: run some tests, to adapt to one's setup...
- cp_test_count.pl: show percent of late transactions
- avg.py: show stats about stuff
sh> grep 'progress: ' OUTPUT_FILE | cut -d' ' -f4 | avg.py
*BEWARE* that if pgbench got stuck some "0" data are missing,
look for the actual tps in the output file and for the line
count to check whether it is the case... some currently submitted
patch on pgbench helps, see https://commitfest.postgresql.org/5/199/
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
avg.py | text/x-python | 2.0 KB |
cp_test.sh | application/x-sh | 4.9 KB |
cp_test_counts.pl | text/x-perl | 611 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2015-06-27 08:07:54 | Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?) |
Previous Message | Michael Paquier | 2015-06-27 06:07:05 | Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?) |