Re: Improving replay of XLOG_BTREE_VACUUM records
От | Simon Riggs |
---|---|
Тема | Re: Improving replay of XLOG_BTREE_VACUUM records |
Дата | |
Msg-id | CANP8+jJwjNSfJo8aDn4jB7WKvN3rPLfYoVXrFP36qnwuLBmYCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improving replay of XLOG_BTREE_VACUUM records (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Improving replay of XLOG_BTREE_VACUUM records
|
Список | 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: