On 8 January 2016 at 13:36, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Vladimir Borodin wrote: > > > > > 7 янв. 2016 г., в 5:26, Michael Paquier <michael.paqu...@gmail.com> > написал(а): > > > > > > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera > > > <alvhe...@2ndquadrant.com <mailto:alvhe...@2ndquadrant.com>> wrote: > > > >> Would you please have a look at Simon's patch, in particular verify > > >> whether it solves the performance dip in your testing environment? > > >> > https://www.postgresql.org/message-id/CANP8%2BjJuyExr1HnTAdZraWsWkfc-octhug7YPtzPtJcYbyi4pA%40mail.gmail.com > > >> (Note there's an updated patch a few emails down the thread.) > > >> > > >> If it seems to fix the problem for you, I think we should mark yours > > >> rejected and just apply Simon’s. > > > > Ok, I’ll try this patch with my use case. Basically, it’s not so easy > > now since I’ve partitioned that big table to not have such problems > > but there is a way to reproduce it once again. If it helps, I agree > > that my should be rejected in favor of the Simon’s patch because my > > patch just reduces replication lag but Simon’s seems to remove lag at > > all. > > I would agree except for the observation on toast indexes. I think > that's an important enough use case that perhaps we should have both. > The exclusion of toast indexes is something we can remove also, I have recently discovered. When we access toast data we ignore MVCC, but we still have the toast pointer and chunkid to use for rechecking our scan results. So a later patch will add some rechecks. So I don't think it is worth applying this patch now. I should add that I also had a patch that did this, posted earlier IIRC. That is not the reason to reject this, just me pointing out that I'm effectively rejecting my own earlier patch also. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
