Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

Поиск
Список
Период
Сортировка
От Darafei "Komяpa" Praliaskouski
Тема Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Дата
Msg-id CAC8Q8t+-+UDteMoXPNOOBsCxfdr3BBHu2+qBpzB7am1ee5B+Ow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Дерево обсуждения


On Fri, Apr 5, 2019 at 6:58 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@anarazel.de> writes:
> I think the right approach would be to do all of this in heap_insert and
> heap_multi_insert. Whenever starting to work on a page, if INSERT_FROZEN
> is specified, remember whether it is either currently empty, or is
> already marked as all-visible. If previously empty, mark it as all
> visible at the end. If already all visible, there's no need to change
> that. If not yet all-visible, no need to do anything, since it can't
> have been inserted with COPY FREEZE.  Do you see any problem doing it
> that way?

Do we want to add overhead to these hot-spot routines for this purpose?

Sizing the overhead: workflows right now don't end with COPY FREEZE - you need another VACUUM to set maps. 
Anything that lets you skip that VACUUM (and faster than that VACUUM itself) is helping. You specifically asked for it to be skippable with FREEZE anyway.


--
Darafei Praliaskouski

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Why does "toast_tuple_target" allow values below TOAST_TUPLE_TARGET?
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: GiST VACUUM