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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply via email to