Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Date
Msg-id CACjxUsONKuKLO2LssM6z3_eiza4P=5F2Foy1a-3BS12FaZ782g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Responses Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
List pgsql-hackers
On Mon, Feb 27, 2017 at 7:35 AM, Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
> Kevin Grittner <kgrittn@gmail.com> writes:
>
>> It occurred to me that it would make sense to allow these settings
>> to be attached to a database or table (though *not* a role).  I'll
>> look at that when I get back if you don't get to it first.
>
> Attached is a draft patch (no docs or tests) on top of the previous one,
> adding reloptions for the per-relation and per-page thresholds.  That
> made me realise that the corresponding GUCs don't need to be PGC_SIGHUP,
> but could be PGC_SUSET or PGC_USERSET.  I'll adjust the original patch
> if you agree.  I have not got around around to adding per-database
> versions of the setting, but could have a stab at that.

Unfortunately, I was unable to get the follow-on patch to allow
setting by relation into a shape I liked.  Let's see what we can do
for the next release.  The first patch was applied with only very
minor tweaks.  I realize that nothing would break if individual
users could set their granularity thresholds on individual
connections, but as someone who has filled the role of DBA, the
thought kinda made my skin crawl.  I left it as PGC_SIGHUP for now;
we can talk about loosening that up later, but I think we should
have one or more use-cases that outweigh the opportunities for
confusion and bad choices by individual programmers to justify that.

--
Kevin Grittner



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] valgrind errors around dsa.c
Next
From: Kevin Grittner
Date:
Subject: Re: [HACKERS] recent deadlock regression test failures