From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>,Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>,Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>,Dmitry Dolgov <9erthalion6(at)gmail(dot)com>,Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POC: Cleaning up orphaned files using undo logs |
Date: | 2019-08-22 16:24:58 |
Message-ID: | EE785235-008B-4C59-B726-3C35691339C0@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
On August 22, 2019 9:14:10 AM PDT, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> But, those requests will
>ultimately be used for collecting the record by the bulk fetch. So if
>we are planning to change the bulk fetch to read forward then maybe we
>don't need the valid last undo record pointer because that we will
>anyway get while processing forward. So just knowing the end of the
>transaction is sufficient for us to know where to stop. I am not sure
>if this solution has any problem. Probably I should think again in
>the morning when my mind is well-rested.
I don't think we can easily do so for bulk apply without incurring significant overhead. It's pretty cheap to read in forward order and then process backwards on a page level - but for an entire transactions undo the story is different. We can't necessarily keep all of it in memory, so we'd have to read the undo twice to find the end. Right?
Andres
Andres
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2019-08-22 17:15:55 | Re: POC: Cleaning up orphaned files using undo logs |
Previous Message | Tom Lane | 2019-08-22 16:19:06 | Re: mingw32 floating point diff |