From: Stephen Frost <sfrost@snowman.net>
To: Joshua D. Drake <jd@commandprompt.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Greg Stark <stark@mit.edu>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Rajeev rastogi <rajeev.rastogi@huawei.com>
Cc: Markus Wanner <markus@bluegap.ch>
Cc: Ants Aasma <ants@cybertec.at>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: obartunov <obartunov@postgrespro.ru>
Cc: Teodor Sigaev <teodor@postgrespro.ru>
Subject: Re: Proposal for CSN based snapshots
Date: Wed, 10 Aug 2016 12:04:19 -0400
Message-ID: <20160810160419.GH4028@tamriel.snowman.net> (raw)
In-Reply-To: <3406288c-9989-5c95-4445-5443b7a7b66f@commandprompt.com>
References: <CA+Tgmob1DmDsvc7iyd0SY5j4SFdesDwoef36bxG1pE_s1JQXOQ@mail.gmail.com>
<CANP8+jLyhL92eJi7RVX_yvbKjxm9=OBKcmNnodaYmeE+o2i1+Q@mail.gmail.com>
<CAPpHfdv7BMwGv=OfUg3S-jGVFKqHi79pR_ZK1Wsk-13oZ+cy5g@mail.gmail.com>
<69041c5a-ec60-3c54-49d0-5df071b27f52@iki.fi>
<a7e33ad4-cf1e-2e7c-6752-de91302292dc@iki.fi>
<79213506-4c9c-7e7a-44c6-ae94484c1159@iki.fi>
<6906.1470840684@sss.pgh.pa.us>
<8c150c9d-6ba2-69fd-e908-ed2fc2775c05@iki.fi>
<CA+TgmoaZizCOkfJ4uuepBqJ0PSrBYnCDEaUk8xoK3SEbnSMGZQ@mail.gmail.com>
<3406288c-9989-5c95-4445-5443b7a7b66f@commandprompt.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
* Joshua D. Drake (jd@commandprompt.com) wrote:
> +1 for Robert here, removing async commit is a non-starter. It is
> PostgreSQL performance 101 that you disable synchronous commit
> unless you have a specific data/business requirement that needs it.
> Specifically because of how much faster Pg is with async commit.
I agree that we don't want to get rid of async commit, but, for the
archive, I wouldn't recommend using it unless you specifically understand
and accept that trade-off, so I wouldn't lump it into a "PostgreSQL
performance 101" group- that's increasing work_mem, shared_buffers, WAL
size, etc. Accepting that you're going to lose *committed* transactions
on a crash requires careful thought and consideration of what you're
going to do when that happens, not the other way around.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, jd@commandprompt.com, robertmhaas@gmail.com, hlinnaka@iki.fi, tgl@sss.pgh.pa.us, a.korotkov@postgrespro.ru, simon@2ndquadrant.com, dilipbalaut@gmail.com, pgsql@j-davis.com, alvherre@2ndquadrant.com, stark@mit.edu, andres@2ndquadrant.com, rajeev.rastogi@huawei.com, markus@bluegap.ch, ants@cybertec.at, bruce@momjian.us, obartunov@postgrespro.ru, teodor@postgrespro.ru
Subject: Re: Proposal for CSN based snapshots
In-Reply-To: <20160810160419.GH4028@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox