| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com> |
| Subject: | Re: WAL consistency check facility |
| Date: | 2016-09-01 04:13:33 |
| Message-ID: | CAM3SWZRfDcv-nHH=V_J-HEcSvN6fqkLFJNj5j7P=D01guN7JiA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 31, 2016 at 8:26 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> As far as I am understanding things, we are aiming at something that
>> could be used on production systems.
>>
>
> I don't think you can enable it by default in production systems.
> Enabling it will lead to significant performance drop as it writes the
> whole page after each record for most type of RMGR ID's.
>
>> And, honestly, any people
>> enabling it would just do it for all RMGRs because that's a
>> no-brainer.
>
> Agreed, but remember enabling it for all is not free.
I have sympathy for the idea that this should be as low overhead as
possible, even if that means adding complexity to the interface --
within reason. I would like to hear a practical example of where this
RMGR id interface could be put to good use, when starting with little
initial information about a problem. And, ideally, we'd also have some
indication of how big a difference that would make, it terms of
measurable performance impact.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2016-09-01 04:41:57 | pg_recvlogical --endpos |
| Previous Message | Craig Ringer | 2016-09-01 04:08:49 | [PATCH] Logical decoding timeline following take II |