Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < - Mailing list pgsql-committers

From David Steele
Subject Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Date
Msg-id 5713AFE2.1000505@pgmasters.net
Whole thread Raw
In response to Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Andres Freund <andres@anarazel.de>)
List pgsql-committers
On 4/16/16 4:44 PM, Noah Misch wrote:

> The key judgment to finalize here is whether it's okay to release this feature
> given its current effect[1], when enabled, on performance.  That is more
> controversial than the potential ~2% regression for old_snapshot_threshold=-1.
> Alvaro[2] and Robert[3] are okay releasing that way, and Andres[4] is not.  If
> anyone else wants to weigh in, now is the time.

I'm in favor of releasing the feature even with the performance
regression when enabled.  First, there are use cases where a feature
like this is absolutely critical.  Second, I don't think it will improve
and become performant without exposure to a wider audience.

I think it's entirely within the PostgreSQL philosophy to release a
feature that has warts and doesn't perform as well as we'd like as long
as it is stable and does not corrupt data.

In my opinion this feature meets these criteria and it is an important
capability to add to PostgreSQL.

--
-David
david@pgmasters.net


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Avoid code duplication in \crosstabview.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.