On Tue, Nov 19, 2019 at 3:39 PM k.jami...@fujitsu.com
wrote:
>
> On Wed, Nov 13, 2019 5:34PM (GMT+9), Fujii Masao wrote:
> > On Wed, Nov 13, 2019 at 3:57 PM k.jami...@fujitsu.com
> >
> > wrote:
> > >
> > > On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrote:
> > > > On Tue, Jul 10, 2018 at 3:04 PM
On Wed, Nov 13, 2019 5:34PM (GMT+9), Fujii Masao wrote:
> On Wed, Nov 13, 2019 at 3:57 PM k.jami...@fujitsu.com
> wrote:
> >
> > On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrote:
> > > On Tue, Jul 10, 2018 at 3:04 PM Michael Paquier
> wrote:
> > > >
> > > > On Thu, Jul 05, 2018 at 01:42:20AM
On Wed, Nov 13, 2019 at 3:57 PM k.jami...@fujitsu.com
wrote:
>
> On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrote:
> > On Tue, Jul 10, 2018 at 3:04 PM Michael Paquier wrote:
> > >
> > > On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> > > > TBH, I have no numbers measured by the
On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrote:
> On Tue, Jul 10, 2018 at 3:04 PM Michael Paquier wrote:
> >
> > On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> > > TBH, I have no numbers measured by the test.
> > > One question about your test is; how did you measure the
On Tue, Jul 10, 2018 at 3:04 PM Michael Paquier wrote:
>
> On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> > TBH, I have no numbers measured by the test.
> > One question about your test is; how did you measure the *recovery time*
> > of DROP DATABASE? Since it's *recovery*
On Thu, Jul 5, 2018 at 5:15 PM Simon Riggs wrote:
>
> On 4 June 2018 at 17:46, Fujii Masao wrote:
> > Hi,
> >
> > My colleague encountered the problem that WAL replay took a long time
> > in the standby with large shared_buffers when he dropped the database
> > using many tablespaces. As far as
On Tue, Jul 10, 2018 at 03:04:05PM +0900, Michael Paquier wrote:
> It would be simple to measure the time it takes to replay this single
> DROP DATABASE record by putting two gettimeofday() calls or such things
> and then take the time difference. There are many methods that you
> could use here,
On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> TBH, I have no numbers measured by the test.
> One question about your test is; how did you measure the *recovery time*
> of DROP DATABASE? Since it's *recovery* performance, basically it's not easy
> to measure that.
It would be
On 4 June 2018 at 17:46, Fujii Masao wrote:
> Hi,
>
> My colleague encountered the problem that WAL replay took a long time
> in the standby with large shared_buffers when he dropped the database
> using many tablespaces. As far as I read the code, this happens because
> DROP DATABASE generates
On Wed, Jul 4, 2018 at 4:47 PM, Jamison, Kirk wrote:
> Hi, Fujii-san
>
> I came across this post and I got interested in it,
> so I tried to apply/test the patch but I am not sure if I did it correctly.
> I set-up master-slave sync, 200GB shared_buffers, 2
> max_locks_per_transaction,
> 1
Hi, Fujii-san
I came across this post and I got interested in it,
so I tried to apply/test the patch but I am not sure if I did it correctly.
I set-up master-slave sync, 200GB shared_buffers, 2
max_locks_per_transaction,
1 DB with 500 table partitions shared evenly across 5 tablespaces.
On Mon, Jun 4, 2018 at 9:46 AM, Fujii Masao wrote:
> Generally the recovery performance of DROP DATABASE is not critical
> for many users. But unfortunately my colleague's project might need to
> sometimes drop the database using multiple tablespaces, for some reasons.
> So, if the fix is not so
12 matches
Mail list logo
