Kevin Grittner writes:
> 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.
Okay, I'll try and crete a more comprehensive version of it for the next
commitfest.
> The first patch was appli
On Mon, Feb 27, 2017 at 7:35 AM, Dagfinn Ilmari Mannsåker
wrote:
> Kevin Grittner 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.
>
>
Kevin Grittner 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,
a
On Tue, Jan 24, 2017 at 3:32 AM, Kevin Grittner wrote:
> I will need some time to consider that
Moved to CF 2017-03 for now. The last patch sent still applies.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Mon, Jan 23, 2017 at 9:50 AM, Dagfinn Ilmari Mannsåker
wrote:
> [new patch addressing issues raised]
Thanks!
>> In releases prior to this patch, max_pred_locks_per_relation was
>> calculated as "max_pred_locks_per_transaction / 2". I know that
>> people have sometimes increased max_pred_loc
On Mon, Jan 23, 2017 at 9:50 AM, Dagfinn Ilmari Mannsåker
wrote:
> Kevin Grittner writes:
>
>> (1) The new GUCs are named max_pred_locks_per_*, but the
>> implementation passes them unmodified from a function specifying at
>> what count the lock should be promoted. We either need to change
>> t
Kevin Grittner writes:
> (1) The new GUCs are named max_pred_locks_per_*, but the
> implementation passes them unmodified from a function specifying at
> what count the lock should be promoted. We either need to change
> the names or (probably better, only because I can't think of a good
> name
A couple things occurred to me after hitting "Send".
In addition to the prior 2 points:
(3) The documentation for max_pred_locks_per_relation needs a fix.
Both page locks and tuple locks for the relation are counted toward
the limit.
In releases prior to this patch, max_pred_locks_per_relation
On Thu, Jan 5, 2017 at 12:19 PM, Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>>> One thing I don't like about this patch is that if a user has increased
>>> max_pred_locks_per_transaction, they need
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>> One thing I don't like about this patch is that if a user has increased
>> max_pred_locks_per_transaction, they need to set
>> max_pred_locks_per_relation to half of that
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> One thing I don't like about this patch is that if a user has increased
> max_pred_locks_per_transaction, they need to set
> max_pred_locks_per_relation to half of that to retain the current
> behaviour, or they'll suddenly find themselves wit
Kevin Grittner writes:
> On Wed, Dec 14, 2016 at 8:16 AM, Dagfinn Ilmari Mannsåker
> wrote:
>
>> Attached is a patch
>
> Please add this to the open CommitFest to ensure that it is reviewed.
Done.
https://commitfest.postgresql.org/12/910/
--
"The surreality of the universe tends towards a ma
On Wed, Dec 14, 2016 at 8:16 AM, Dagfinn Ilmari Mannsåker
wrote:
> Attached is a patch
Please add this to the open CommitFest to ensure that it is reviewed.
http://commitfest.postgresql.org/action/commitfest_view/open
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQ
13 matches
Mail list logo
