| From: | Jim Nasby <jim(dot)nasby(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
| Date: | 2024-01-16 21:28:32 |
| Message-ID: | ac69f6da-59d4-4545-8186-f56f568dafa7@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/12/24 12:45 PM, Robert Haas wrote:
> P.P.S. to everyone: Yikes, this logic is really confusing.
Having studied all this code several years ago when it was even simpler
- it was *still* very hard to grok even back then. I *greatly
appreciate* the effort that y'all are putting into increasing the
clarity here.
BTW, back in the day the whole "no indexes" optimization was a really
tiny amount of code... I think it amounted to 2 or 3 if statements. I
haven't yet attempted to grok this patchset, but I'm definitely
wondering how much it's worth continuing to optimize that case. Clearly
it'd be very expensive to memoize dead tuples just to trawl that list a
single time to clean the heap, but outside of that I'm not sure other
optimazations are worth it given the amount of code
complexity/duplication they seem to require - especially for code where
correctness is so crucial.
--
Jim Nasby, Data Architect, Austin TX
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-01-16 21:46:09 | Re: [PATCH] Add support function for containment operators |
| Previous Message | Jelte Fennema-Nio | 2024-01-16 21:19:31 | Re: UUID v7 |