Re: Avoiding pin scan during btree vacuum
От | Simon Riggs |
---|---|
Тема | Re: Avoiding pin scan during btree vacuum |
Дата | |
Msg-id | CANP8+jKRzavabk5J0a_XbWjqEeUX+vfn-K4hkkMoJ1vNR4bCUQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoiding pin scan during btree vacuum (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Avoiding pin scan during btree vacuum
|
Список | pgsql-hackers |
On 21 December 2015 at 21:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
--
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I think the new comment that talks about Toast Index should explain
> *why* we can skip the pinning in all cases except that one, instead of
> just saying we can do it.
I've not looked at that code in a long while, but my recollection is
that it's designed that way to protect non-MVCC catalog scans, which
are gone now ... except for SnapshotToast.
Yes, that's the principle in use here. Which means we can optimize away the scan on a Hot Standby in all cases except for Toast Index vacuums.
Maybe the right way to
approach this is to adjust HeapTupleSatisfiesToast (or maybe just
convince ourselves that no one could be dereferencing a stale toast
pointer in the first place?) and then redesign btree vacuuming without
the requirement to support non-MVCC scans, period.
We could, but its likely to be a much more complex patch.
I'm happy with this being a simple patch now, not least because I would like to backpatch this to 9.4 where catalog scans became MVCC.
A backpatch is warranted because it is a severe performance issue with replication and we can fix that before 9.5 hits the streets.
I'll be doing some more testing and checking, so not in a rush.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: