On Tue, Sep 5, 2023 at 1:40 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > > On Wed, Jun 21, 2023 at 8:51 AM James Coleman <jtc...@gmail.com> wrote: > > While at PGCon I was chatting with Andres (and I think Peter G. and a > > few others who I can't remember at the moment, apologies) and Andres > > noted that while we opportunistically prune a page when inserting a > > tuple (before deciding we need a new page) we don't do the same for > > updates. > > > > Attached is a patch series to do the following: > > > > 0001: Make it possible to call heap_page_prune_opt already holding an > > exclusive lock on the buffer. > > 0002: Opportunistically prune pages on update when the current tuple's > > page has no free space. If this frees up enough space, then we > > continue to put the new tuple on that page; if not, then we take the > > existing code path and get a new page. > > I've reviewed these patches and have questions. > > Under what conditions would this be exercised for UPDATE? Could you > provide an example? > > With your patch applied, when I create a table, the first time I update > it heap_page_prune_opt() will return before actually doing any pruning > because the page prune_xid hadn't been set (it is set after pruning as > well as later in heap_update() after RelationGetBufferForTuple() is > called). > > I actually added an additional parameter to heap_page_prune() and > heap_page_prune_opt() to identify if heap_page_prune() was called from > RelationGetBufferForTuple() and logged a message when this was true. > Running the test suite, I didn't see any UPDATEs executing > heap_page_prune() from RelationGetBufferForTuple(). I did, however, see > other statement types doing so (see RelationGetBufferForTuple()'s other > callers). Was that intended? > > > I started to work on benchmarking this, but haven't had time to devote > > properly to that, so I'm wondering if there's anyone who might be > > interested in collaborating on that part. > > I'm interested in this feature and in helping with it/helping with > benchmarking it, but I don't yet understand the design in its current > form.
Hi Melanie, Thanks for taking a look at this! Apologies for the long delay in replying: I started to take a look at your questions earlier, and it turned into more of a rabbit hole than I'd anticipated. I've since been distracted by other things. So -- I don't have any conclusions here yet, but I'm hoping at or after PGConf NYC that I'll be able to dedicate the time this deserves. Thanks, James Coleman
