On 2020/10/01 12:56, Masahiro Ikeda wrote:
On 2020-10-01 11:33, Amit Kapila wrote:
On Thu, Oct 1, 2020 at 6:53 AM Kyotaro Horiguchi
wrote:
At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao
wrote in
>
>
> On 2020/09/30 20:21, Amit Kapila wrote:
> > On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao
On Wed, Jan 22, 2020 at 02:38:19PM +0900, Kyotaro Horiguchi wrote:
> I changed my mind to attach the benchmark patch as .txt file,
> expecting the checkers not picking up it as a part of the patchset.
>
> I have in the precise performance measurement mode for a long time,
> but I think it's settle
At Thu, 1 Oct 2020 12:58:19 +0900, Fujii Masao
wrote in
> the table needs to be rewriitten. One idea for that is to improve that
> command
> so that it skips the table rewrite if wal_level=minimal.
> Of course, also you can change wal_level after marking the table as
> unlogged.
tablecmd.c:
>
On Wed, Sep 30, 2020 at 3:00 PM Amit Kapila wrote:
>
> On Wed, Sep 30, 2020 at 12:16 PM Dilip Kumar wrote:
> >
> > On Mon, Sep 28, 2020 at 2:22 PM Amit Kapila wrote:
> > >
> > >
> > > I don't have a patch for this idea but you can refer [1]
> > > (v25-0002-Issue-individual-invalidations-with-wal
At Thu, 1 Oct 2020 12:56:02 +0900, Michael Paquier wrote
in
> On Thu, Oct 01, 2020 at 11:16:53AM +0900, Kyotaro Horiguchi wrote:
> > Thanks. Since it starts all remote nodes before local ones, the
> > startup gain would be the shorter of the startup time of the fastest
> > remote and the time r
On 2020/10/01 13:03, Tatsuo Ishii wrote:
On Thu, Sep 17, 2020 at 09:42:45AM +0900, Tatsuo Ishii wrote:
I am asking because these patch sets are now getting closer to
committable state in my opinion, and if there's someting wrong, it
should be fixed soon so that these patches are getting into
On Tue, Sep 01, 2020 at 10:43:47AM +0900, Michael Paquier wrote:
> As of the moment this message is written, 10 hours remain until we are
> the 1st of September AoE, where I'll switch the commit fest as
> officially in progress. It will not be possible to register new
> patches to 2020-09 after th
On Fri, Sep 25, 2020 at 06:11:47PM +0800, Julien Rouhaud wrote:
> Thanks a lot for the tests! I'm not surprised that forcing the lock
> will slow down the pg_check_relation() execution, but I'm a bit
> surprised that holding the buffer mapping lock longer in a workload
> that has a lot of eviction
On Thu, 1 Oct 2020 13:43:49 +0900
Fujii Masao wrote:
> When I glanced the doc patch (i.e., 0012), I found some typos.
Thank you for your pointing out typos! I'll fix it.
>
> +CRATE INCREMENTAL MATERIALIZED VIEW, for example:
>
> Typo: CRATE should be CREATE ?
>
> +with __ivm_ and
At Thu, 1 Oct 2020 04:20:27 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> From: Kyotaro Horiguchi
> > In more detail, if smgrcachednblocks() returned InvalidBlockNumber for
> > any of the forks, we should give up the optimization at all since we
> > need to run a full scan anyway. On the oth
čt 1. 10. 2020 v 5:38 odesílatel Michael Paquier
napsal:
> On Thu, Sep 24, 2020 at 08:49:50PM +0200, Pavel Stehule wrote:
> > fixed patch attached
>
> It looks like there are again conflicts within setrefs.c.
>
fresh patch
Regards
Pavel
--
> Michael
>
schema-variables-20201001.patch.gz
Desc
On Tue, Sep 29, 2020 at 06:13:46PM -0400, Tom Lane wrote:
> So I wonder why PostgresNode.pm is doing
>
> print $conf "max_wal_senders = 5\n";
>
> Considering that our default these days is 10 senders, and that a
> walsender slot doesn't really cost much, this seems unduly cheapskate
On Thursday, October 1, 2020 11:49 AM, Amit Kapila wrote:
> On Thu, Oct 1, 2020 at 8:11 AM tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Jamison, Kirk/ジャミソン カーク
> > > Recovery performance measurement results below.
> > > But it seems there are overhead even with large shared buffers.
> > >
>
On Thu, Oct 1, 2020 at 6:35 AM Michael Paquier wrote:
> The documentation is failing to build, and the patch does not build
> correctly on Windows. Could you address that?
> --
> Michael
Yes I'm on it.
--
Matthieu
Hi,
On Thu, Oct 1, 2020 at 1:32 PM Michael Paquier wrote:
>
> On Fri, Sep 11, 2020 at 07:20:56PM +0900, Amit Langote wrote:
> > I have been working away at this and have updated the patches for many
> > cosmetic and some functional improvements.
>
> Please note that this patch set fails to apply.
From: Jamison, Kirk/ジャミソン カーク
> For non-recovery path, did you mean by any chance
> measuring the cache hit rate for varying shared_buffers?
No. You can test the speed of DropRelFileNodeBuffers() during normal
operation, i.e. by running TRUNCATE on psql, instead of performing recovery.
To ena
On Wed, Sep 30, 2020 at 4:34 PM Dilip Kumar wrote:
>
> On Wed, Sep 30, 2020 at 2:40 PM Amit Kapila wrote:
> >
> > On Wed, Sep 30, 2020 at 1:12 PM Dilip Kumar wrote:
> > >
> > > On Fri, Sep 25, 2020 at 4:33 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Sep 24, 2020 at 5:44 PM Amit Kapila
On Thu, Oct 1, 2020 at 12:06 PM Amit Kapila wrote:
>
> Thanks for the review.
>
oops, forgot to attach the updated patches, doing now.
--
With Regards,
Amit Kapila.
v7-0001-Track-statistics-for-spilling-of-changes-from-Reo.patch
Description: Binary data
v7-0002-Test-stats.patch
Description:
On Tue, Sep 29, 2020 at 3:16 PM Greg Nancarrow wrote:
>
> Hi Vignesh and Bharath,
>
> Seems like the Parallel Copy patch is regarding RI_TRIGGER_PK as
> parallel-unsafe.
> Can you explain why this is?
>
I don't think we need to restrict this case and even if there is some
reason to do so then pro
101 - 119 of 119 matches
Mail list logo