| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: Opportunistically pruning page before update |
| Date: | 2024-01-23 07:46:19 |
| Message-ID: | CAFiTN-vu+U2HfUPr5u=GhoZvCDDGOZWWZ2g63SMH1+TLC2s=gg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 23, 2024 at 7:18 AM James Coleman <jtc331(at)gmail(dot)com> wrote:
>
> On Mon, Jan 22, 2024 at 8:21 PM James Coleman <jtc331(at)gmail(dot)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?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2024-01-23 07:48:25 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
| Previous Message | Heikki Linnakangas | 2024-01-23 07:43:50 | Re: Multiple startup messages over the same connection |