On Wed, May 13, 2020 at 6:58 AM Peter Geoghegan wrote:
> Shouldn't you close out the "Should we rename
> effective_io_concurrency?" Postgres 13 open item now?
Yeah, that doesn't really seem worth the churn. I'll move it to the
resolved list in a day or two if no one shows up to argue for a
On Sun, Mar 15, 2020 at 9:27 PM Thomas Munro wrote:
> On Tue, Mar 10, 2020 at 12:20 PM Thomas Munro wrote:
> > Here's a patch set to remove the spindle stuff, add a maintenance
> > variant, and use the maintenance one in
> > heap_compute_xid_horizon_for_tuples().
>
> Pushed.
Shouldn't you close
On Tue, Mar 10, 2020 at 12:20 PM Thomas Munro wrote:
> Here's a patch set to remove the spindle stuff, add a maintenance
> variant, and use the maintenance one in
> heap_compute_xid_horizon_for_tuples().
Pushed.
On Sat, Mar 7, 2020 at 9:07 AM Tom Lane wrote:
> Tomas Vondra writes:
> > So I think we should either rename e_i_c or keep it as is, and then also
> > have a new GUC. And then translate the values between those (but that
> > might be overkill).
>
> Please DON'T try to have two interrelated GUCs
On Sat, Mar 7, 2020 at 11:54 PM Evgeniy Shishkin wrote:
> > On Mar 7, 2020, at 00:33, Thomas Munro wrote:
> > That is indeed what led me to start thinking about what a good new
> > name would be.
>
> MySQL has a term io_capacity.
>
> On Mar 7, 2020, at 00:33, Thomas Munro wrote:
>
> That is indeed what led me to start thinking about what a good new
> name would be.
MySQL has a term io_capacity.
https://dev.mysql.com/doc/refman/8.0/en/innodb-configuring-io-capacity.html
> The innodb_io_capacity variable defines the
On Sat, Mar 7, 2020 at 8:35 AM Tomas Vondra
wrote:
> I think the main issue with keeping the current GUC name is that if you
> had a value that worked, we'll silently interpret it differently. Which
> is a bit annoying :-(
Yeah. Perhaps we should just give the formula for translating v12
On Sat, Mar 7, 2020 at 8:00 AM Andres Freund wrote:
> On 2020-03-02 18:28:41 +1300, Thomas Munro wrote:
> > * leaves room for a different setting for sequential prefetching
>
> I think if we want to split those at some point, we ought to split it if
> we have a good reason, not before. It's not
On Sat, Mar 7, 2020 at 9:52 AM Michael Banck wrote:
> On Mon, Mar 02, 2020 at 06:28:41PM +1300, Thomas Munro wrote:
> > * "maintenance_" prefix is like other GUCs that establish (presumably
> > larger) limits for processes working on behalf of many user sessions
>
> I'm a bit skeptical about this
Hi,
On Mon, Mar 02, 2020 at 06:28:41PM +1300, Thomas Munro wrote:
> Should we rename it? Here are my first suggestions:
>
> maintenance_random_page_prefetch_degree
>
> Rationale for this naming pattern:
[...]
> * "maintenance_" prefix is like other GUCs that establish (presumably
> larger)
Tomas Vondra writes:
> So I think we should either rename e_i_c or keep it as is, and then also
> have a new GUC. And then translate the values between those (but that
> might be overkill).
Please DON'T try to have two interrelated GUCs for this. We learned
our lesson about that years ago.
I
On Fri, Mar 06, 2020 at 10:05:13AM -0800, Andres Freund wrote:
Hi,
On 2020-03-02 18:28:41 +1300, Thomas Munro wrote:
I was reading through some old threads[1][2][3] while trying to figure
out how to add a new GUC to control I/O prefetching for new kinds of
things[4][5], and enjoyed Simon
Hi,
On 2020-03-02 18:28:41 +1300, Thomas Munro wrote:
> I was reading through some old threads[1][2][3] while trying to figure
> out how to add a new GUC to control I/O prefetching for new kinds of
> things[4][5], and enjoyed Simon Riggs' reference to Jules Verne in the
> context of RAID
Hello,
I was reading through some old threads[1][2][3] while trying to figure
out how to add a new GUC to control I/O prefetching for new kinds of
things[4][5], and enjoyed Simon Riggs' reference to Jules Verne in the
context of RAID spindles.
On 2 Sep 2015 14:54, "Andres Freund" wrote:
> > On
14 matches
Mail list logo
