Re: Reviewing freeze map code
От | Jim Nasby |
---|---|
Тема | Re: Reviewing freeze map code |
Дата | |
Msg-id | b24fecf9-6dfb-89b7-904c-bef387025614@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Reviewing freeze map code (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 7/1/16 3:43 PM, Andres Freund wrote: > On 2016-07-01 15:42:22 -0500, Jim Nasby wrote: >> On 7/1/16 2:23 PM, Andres Freund wrote: >>>>> The only >>>>> cost of that is that vacuum will come along and mark the page >>>>> all-visible again instead of skipping it, but that's probably not an >>>>> enormous expense in most cases. >>> I think the main cost is not having the page marked as all-visible for >>> index-only purposes. If it's an insert mostly table, it can be a long >>> while till vacuum comes around. >> >> ISTM that's something that should be addressed anyway (and separately), no? > > Huh? That's the current behaviour in heap_lock_tuple. Oh, I was referring to autovac not being aggressive enough on insert-mostly tables. Certainly if there's a reasonable way to avoid invalidating the VM when locking a tuple that'd be good. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461
В списке pgsql-hackers по дате отправления: