Re: Non-reserved replication slots and slot advancing

2018-07-10 Thread Andres Freund
On 2018-07-10 16:59:07 +0900, Michael Paquier wrote: > On Tue, Jul 10, 2018 at 12:26:30AM -0700, Andres Freund wrote: > > Why is the ReplicationSlotRelease() needed here? Souldn't the error > > handling code do so automatically? > > Oh, indeed. I didn't know that PostgresMain was doing some

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

2018-07-10 Thread Haribabu Kommi
On Tue, Jul 10, 2018 at 12:26 AM Fujii Masao wrote: > On Sun, Jul 8, 2018 at 11:48 AM, Haribabu Kommi > wrote: > > > > On Fri, Jul 6, 2018 at 3:22 AM Fujii Masao > wrote: > >> > >> On Wed, Jul 4, 2018 at 7:12 PM, Haribabu Kommi < > kommi.harib...@gmail.com> > >> wrote: > >> > > >> > Update

RE: hostorder and failover_timeout for libpq

2018-07-10 Thread Iwata, Aya
Hello Ildar, I have a question about failover_timeout parameter. Which would be better: implementing the parameter to retry at waiting time or controlling the connection retry on the application side? Also, I have no idea if the amount of random access by hostorder parameter will have a good

Re: Non-reserved replication slots and slot advancing

2018-07-10 Thread Michael Paquier
On Tue, Jul 10, 2018 at 12:26:30AM -0700, Andres Freund wrote: > Why is the ReplicationSlotRelease() needed here? Souldn't the error > handling code do so automatically? Oh, indeed. I didn't know that PostgresMain was doing some cleanup here. There is a second place where this can be removed,

Re: Non-reserved replication slots and slot advancing

2018-07-10 Thread Andres Freund
Hi, On 2018-07-10 09:54:28 +0900, Michael Paquier wrote: > > > Also, ERRCODE_FEATURE_NOT_SUPPORTED doesn't quite seem right. How about > > > ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE? > > > > +1 to both of Andres' suggestions. > > Those indeed sound better. What do you think of the attached?

Re: Recovery performance of standby for multiple concurrent truncates on large tables

2018-07-10 Thread Andres Freund
Hi, On 2018-07-10 07:05:12 +, Jamison, Kirk wrote: > Hello hackers, > > Recently, the problem on improving performance of multiple drop/truncate > tables in a single transaction with large shared_buffers (as shown below) was > solved by commit b416691. > BEGIN; >

Recovery performance of standby for multiple concurrent truncates on large tables

2018-07-10 Thread Jamison, Kirk
Hello hackers, Recently, the problem on improving performance of multiple drop/truncate tables in a single transaction with large shared_buffers (as shown below) was solved by commit b416691. BEGIN; truncate tbl001; ... truncate tbl050;

Re: Performance regression with PostgreSQL 11 and partitioning

2018-07-10 Thread Christophe Courtois
Hi, Le 09/07/2018 à 22:10, David Rowley a écrit : > On 10 July 2018 at 00:47, Christophe Courtois > wrote: > (Christophe reports 2x performance regression with PG11 when using > 1 partitions) > Thanks for the report. Can you supply your test case when shows this > regression? > Please, can

Re: Let's remove DSM_IMPL_NONE.

2018-07-10 Thread Kyotaro HORIGUCHI
Thank you for the notice. At Mon, 9 Jul 2018 12:30:22 +0300, Arthur Zakirov wrote in <20180709093021.GA9309@zakirov.localdomain> > Hello, > > On Mon, Jul 09, 2018 at 06:07:24PM +0900, Kyotaro HORIGUCHI wrote: > > The new version v4 is changed in the following points. > > > > - Don't renumber

Re: Recovery performance of DROP DATABASE with many tablespaces

2018-07-10 Thread Michael Paquier
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

<    1   2