Re: Improving replay of XLOG_BTREE_VACUUM records - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Improving replay of XLOG_BTREE_VACUUM records
Date
Msg-id CANP8+jJwjNSfJo8aDn4jB7WKvN3rPLfYoVXrFP36qnwuLBmYCg@mail.gmail.com
Whole thread Raw
In response to Re: Improving replay of XLOG_BTREE_VACUUM records  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Improving replay of XLOG_BTREE_VACUUM records  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 8 January 2016 at 13:36, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Vladimir Borodin wrote:
>
> > 7 янв. 2016 г., в 5:26, Michael Paquier <michael.paquier@gmail.com> написал(а):
> >
> > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera
> > <alvherre@2ndquadrant.com <mailto:alvherre@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

pgsql-hackers by date:

Previous
From: Vitaly Burovoy
Date:
Subject: Re: New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"
Next
From: Simon Riggs
Date:
Subject: Re: New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"