Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-08-30 Thread Daniel Farina
On Tue, Mar 13, 2012 at 4:53 PM, Josh Berkus j...@agliodbs.com wrote: 4. On a high-UPDATE workload, this means that the replica assumes tables have no free space until it starts to build a new FSM or autovacuum kicks in on some of the tables, much later on. 5. If your hosting is such that you

Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-08-30 Thread Tom Lane
Daniel Farina dan...@heroku.com writes: but just today we promoted another system via streaming replication to pick up the planner fix in 9.1.5 (did you know: that planner bug seems to make GIN FTS indexes un-used in non-exotic cases, and one goes to seqscan?), and then a 40MB GIN index

Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-03-21 Thread Heikki Linnakangas
On 20.03.2012 23:41, Josh Berkus wrote: Heikki, The FSM is included in the base backup, and it is updated when VACUUM records are replayed. Oh? H. In that case, the issue I'm seeing in production is something else. Unless that was a change for 9.1? No, it's been like that since

Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-03-20 Thread Josh Berkus
Heikki, The FSM is included in the base backup, and it is updated when VACUUM records are replayed. Oh? H. In that case, the issue I'm seeing in production is something else. Unless that was a change for 9.1? It is also updated when insert/update/delete records are replayed, athough

Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-03-14 Thread Heikki Linnakangas
On 14.03.2012 01:53, Josh Berkus wrote: 1. The Free Space Map is not replicated between servers. 2. Thus, when we fail over to a replica, it starts with a blank FSM. The FSM is included in the base backup, and it is updated when VACUUM records are replayed. It is also updated when

[HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-03-13 Thread Josh Berkus
All, I've discovered a built-in performance issue with replication failover at one site, which I couldn't find searching the archives. I don't really see what we can do to fix it, so I'm posting it here in case others might have clever ideas. 1. The Free Space Map is not replicated between

Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-03-13 Thread Daniel Farina
On Tue, Mar 13, 2012 at 4:53 PM, Josh Berkus j...@agliodbs.com wrote: All, I've discovered a built-in performance issue with replication failover at one site, which I couldn't find searching the archives.  I don't really see what we can do to fix it, so I'm posting it here in case others

Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-03-13 Thread Fujii Masao
On Wed, Mar 14, 2012 at 8:53 AM, Josh Berkus j...@agliodbs.com wrote: All, I've discovered a built-in performance issue with replication failover at one site, which I couldn't find searching the archives.  I don't really see what we can do to fix it, so I'm posting it here in case others

Re: [HACKERS] Chronic performance issue with Replication Failover and FSM.

2012-03-13 Thread Daniel Farina
On Tue, Mar 13, 2012 at 7:05 PM, Fujii Masao masao.fu...@gmail.com wrote: If it's really a high-UPDATE workload, wouldn't autovacuum start soon? Also, while vacuum cleanup records are applied, could not the standby also update its free space map, without having to send the actual FSM updates? I