Re: [PoC] Improve dead tuple storage for lazy vacuum - Mailing list pgsql-hackers
From | Masahiko Sawada |
---|---|
Subject | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Date | |
Msg-id | CAD21AoA1N0jG9Tit-wcF=CVb8Bdtw3r_MG5sYN=HFNbzvcLiSg@mail.gmail.com Whole thread Raw |
In response to | Re: [PoC] Improve dead tuple storage for lazy vacuum (John Naylor <johncnaylorls@gmail.com>) |
Responses |
Re: [PoC] Improve dead tuple storage for lazy vacuum
|
List | pgsql-hackers |
On Mon, Apr 15, 2024 at 6:12 PM John Naylor <johncnaylorls@gmail.com> wrote: > > I took a look at the coverage report from [1] and it seems pretty > good, but there are a couple more tests we could do. Thank you for checking! > > - RT_KEY_GET_SHIFT is not covered for key=0: > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L803 > > That should be fairly simple to add to the tests. There are two paths to call RT_KEY_GET_SHIFT(): 1. RT_SET() -> RT_KEY_GET_SHIFT() 2. RT_SET() -> RT_EXTEND_UP() -> RT_KEY_GET_SHIFT() In both cases, it's called when key > tree->ctl->max_val. Since the minimum value of max_val is 255, RT_KEY_GET_SHIFT() is never called when key=0. > > - Some paths for single-value leaves are not covered: > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L904 > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L954 > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L2606 > > However, these paths do get regression test coverage on 32-bit > machines. 64-bit builds only have leaves in the TID store, which > doesn't (currently) delete entries, and doesn't instantiate the tree > with the debug option. Right. > > - In RT_SET "if (found)" is not covered: > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L1768 > > That's because we don't yet have code that replaces an existing value > with a value of a different length. Noah reported an issue around that. We should incorporate the patch and cover this code path. > > - RT_FREE_RECURSE isn't well covered: > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L1768 > > The TID store test is pretty simple as far as distribution of block > keys, and focuses more on the offset bitmaps. We could try to cover > all branches here, but it would make the test less readable, and it's > kind of the wrong place to do that anyway. test_radixtree.c does have > a commented-out option to use shared memory, but that's for local > testing and won't be reflected in the coverage report. Maybe it's > enough. Agreed. > > - RT_DELETE: "if (key > tree->ctl->max_val)" is not covered: > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L2644 > > That should be easy to add. Agreed. The patch is attached. > > - RT_DUMP_NODE is not covered, and never called by default anyway: > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L2804 > > It seems we could just leave it alone since it's debug-only, but it's > also a lot of lines. One idea is to use elog with DEBUG5 instead of > commenting out the call sites, but that would cause a lot of noise. I think we can leave it alone. > > - TidStoreCreate* has some memory clamps that are not covered: > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/access/common/tidstore.c.gcov.html#L179 > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/access/common/tidstore.c.gcov.html#L234 > > Maybe we could experiment with using 1MB for shared, and something > smaller for local. I've confirmed that the local and shared tidstore with small max sizes such as 4kB and 1MB worked. Currently the max size is hard-coded in test_tidstore.c but if we use work_mem as the max size, we can pass different max sizes for local and shared in the test script. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
Attachment
pgsql-hackers by date: