Re: Opportunistically pruning page before update

Поиск
Список
Период
Сортировка
От James Coleman
Тема Re: Opportunistically pruning page before update
Дата
Msg-id CAAaqYe-bS+nDA=APKy9JQSWKU6tT6Gkph3Vkv4pCaFZ=S9BJxQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Opportunistically pruning page before update  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Opportunistically pruning page before update
Re: Opportunistically pruning page before update
Список pgsql-hackers
On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Tue, Jan 23, 2024 at 7:18 AM James Coleman <jtc331@gmail.com> wrote:
> >
> > On Mon, Jan 22, 2024 at 8:21 PM James Coleman <jtc331@gmail.com> wrote:
> > >
> > > See rebased patch attached.
> >
> > I just realized I left a change in during the rebase that wasn't necessary.
> >
> > v4 attached.
>
> I have noticed that you are performing the opportunistic pruning after
> we decided that the updated tuple can not fit in the current page and
> then we are performing the pruning on the new target page.  Why don't
> we first perform the pruning on the existing page of the tuple itself?
>  Or this is already being done before this patch? I could not find
> such existing pruning so got this question because such pruning can
> convert many non-hot updates to the HOT update right?

First off I noticed that I accidentally sent a different version of
the patch I'd originally worked on. Here's the one from the proper
branch. It's still similar, but I want to make sure the right one is
being reviewed.

I'm working on a demo case for updates (to go along with the insert
case I sent earlier) to test out your question, and I'll reply when I
have that.

Regards,
James Coleman

Вложения

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

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Bug: The "directory" control parameter does not work
Следующее
От: vignesh C
Дата:
Сообщение: Re: [PoC/RFC] Multiple passwords, interval expirations