Re: Some questions about old_snapshot_threshold

From: Marc-Olaf Jaschke <moj(at)dshare(dot)de>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Some questions about old_snapshot_threshold
Date: 2016-12-05 14:52:50
Message-ID: 6EFE5E78-1EAA-4796-BF7E-7A36283A8EB8@dshare.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Thanks for the explanation!

Best Regards,
Marc-Olaf

> Am 28.11.2016 um 22:47 schrieb Kevin Grittner <kgrittn(at)gmail(dot)com>:
>
> On Fri, Nov 25, 2016 at 1:39 PM, Marc-Olaf Jaschke <moj(at)dshare(dot)de> wrote:
>
>> 1. The following presentation uses serializable transaction
>> isolation level to force a snapshot too old error.
>> (http://momjian.us/main/writings/pgsql/features.pdf)
>> Is it possible to get a snapshot too old error with active
>> old_snapshot_threshold when the only used transaction isolation
>> level is read committed?
>
> Yes. Transaction isolation level doesn't have much impact on this
> feature.
>
>> 2. Does activating old_snapshot_threshold have a negative impact
>> on peformance?
>
> The latest tests, near the end of development, were run by Tomas
> Vondra and are reported here:
>
> https://www.postgresql.org/message-id/067acb3d-80eb-279d-fce0-90e0a36c6aa2@2ndquadrant.com
>
> Note that the "immediate" lines are using a setting of zero, which
> is ridiculously aggressive, and only intended for testing purposes.
> The lines ending in "-10-rw" are using a 10 minute expiration,
> which is still far more aggressive than I would expect most
> environments to use, but should give some idea what the impact
> could be "worst case". Tomas says in the linked email, "I'm
> personally convinced the performance impact is within noise."
>
> FWIW, it makes no sense to enable this feature with a read-only
> workload, but that configuration was heavily tested, as it
> represents a worst case. Also note that Tomas used a multi-socket
> NUMA machine for these tests, because that is where we saw the
> largest differences during early tests, before some optimizations
> were applied.
>
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tharmarajah, Sam 2016-12-05 18:57:59 Req. for some help with resolving the error "pg_basebackup: could not get WAL end position from server: FATAL: requested WAL segment"
Previous Message Peter Eisentraut 2016-12-02 14:41:47 Re: restoring 9.3 dump file to 9.6