On Sat, Sep 30, 2023 at 1:02 PM Andres Freund wrote:
> The only thought I have is that it might be worth to amend the comment in
> lazy_scan_prune() to mention that such a tuple won't need to be frozen,
> because it was visible to another session when vacuum started.
I revised the comment a bit,
Hi,
On 2023-09-28 11:25:04 -0400, Robert Haas wrote:
> I went ahead and committed 0001. If Andres still wants to push for
> more renaming there, that can be a follow-up patch.
Agreed.
> And we can see if he or anyone else has any comments on this new version of
> 0002. To me we're down into the
On Thu, Sep 28, 2023 at 8:46 AM Melanie Plageman
wrote:
> Once I started writing the function comment, however, I felt a bit
> awkward. In order to make the function available to both pruneheap.c
> and vacuumlazy.c, I had to put it in a header file. Writing a
> function, available to anyone includ
On Thu, Sep 21, 2023 at 3:53 PM Robert Haas wrote:
>
> On Wed, Sep 13, 2023 at 1:29 PM Andres Freund wrote:
>
> > > /*
> > >* The criteria for counting a tuple as live in this block
> > > need to
> > > @@ -1682,7 +1664,7 @@ retry:
> > >* (Cases where
On Thu, Sep 21, 2023 at 3:53 PM Robert Haas wrote:
> > > static int heap_prune_chain(Buffer buffer,
> > >OffsetNumber
> > > rootoffnum,
> > > + int8 *htsv,
> > >
[ sorry for the delay getting back to this ]
On Wed, Sep 13, 2023 at 1:29 PM Andres Freund wrote:
> I think it might be worth making the names a bit less ambiguous than they
> were. It's a bit odd that one has "new" in the name, the other doesn't,
> despite both being about newly marked things. A
Hi,
On 2023-09-07 18:23:22 -0400, Melanie Plageman wrote:
> From e986940e546171d1f1d06f62a101d695a8481e7a Mon Sep 17 00:00:00 2001
> From: Melanie Plageman
> Date: Wed, 6 Sep 2023 14:57:20 -0400
> Subject: [PATCH v4 2/3] Move heap_page_prune output parameters into struct
>
> Add PruneResult, a s
On Fri, Sep 8, 2023 at 11:06 AM Robert Haas wrote:
>
> On Thu, Sep 7, 2023 at 6:23 PM Melanie Plageman
> wrote:
> > I mostly wanted to remove the NULL checks because I found them
> > distracting (so, a stylistic complaint). However, upon further
> > reflection, I actually think it is better if he
On Thu, Sep 7, 2023 at 6:23 PM Melanie Plageman
wrote:
> I mostly wanted to remove the NULL checks because I found them
> distracting (so, a stylistic complaint). However, upon further
> reflection, I actually think it is better if heap_page_prune_opt()
> passes NULL. heap_page_prune() has no erro
On Thu, Sep 7, 2023 at 3:30 PM Robert Haas wrote:
>
> On Thu, Sep 7, 2023 at 3:10 PM Melanie Plageman
> wrote:
> > I can fix it by changing the type of PruneResult->off_loc to be an
> > OffsetNumber pointer. This does mean that PruneResult will be
> > initialized partially by heap_page_prune() ca
On Thu, Sep 7, 2023 at 3:10 PM Melanie Plageman
wrote:
> I can fix it by changing the type of PruneResult->off_loc to be an
> OffsetNumber pointer. This does mean that PruneResult will be
> initialized partially by heap_page_prune() callers. I wonder if you
> think that undermines the case for mak
On Thu, Sep 7, 2023 at 1:37 PM Robert Haas wrote:
>
> On Wed, Sep 6, 2023 at 5:21 PM Melanie Plageman
> wrote:
> > Yeah, I think this is a fair concern. I have addressed it in the
> > attached patches.
> >
> > I thought a lot about whether or not adding a PruneResult which
> > contains only the o
On Wed, Sep 6, 2023 at 5:21 PM Melanie Plageman
wrote:
> Yeah, I think this is a fair concern. I have addressed it in the
> attached patches.
>
> I thought a lot about whether or not adding a PruneResult which
> contains only the output parameters and result of heap_page_prune() is
> annoying sinc
On Wed, Sep 6, 2023 at 1:04 PM Robert Haas wrote:
>
> On Thu, Aug 31, 2023 at 6:29 PM Melanie Plageman
> wrote:
> > I have changed this.
>
> I spent a bunch of time today looking at this, thinking maybe I could
> commit it. But then I got cold feet.
>
> With these patches applied, PruneResult end
On Thu, Aug 31, 2023 at 6:29 PM Melanie Plageman
wrote:
> I have changed this.
I spent a bunch of time today looking at this, thinking maybe I could
commit it. But then I got cold feet.
With these patches applied, PruneResult ends up being declared in
heapam.h, with a comment that says /* State
Hi,
On 9/1/23 03:25, Peter Geoghegan wrote:
On Thu, Aug 31, 2023 at 3:35 PM Melanie Plageman
wrote:
Any inserting transaction which aborts after heap_page_prune()'s
visibility check will now be of no concern to lazy_scan_prune(). Since
we don't do the visibility check again, we won't find the
On Thu, Aug 31, 2023 at 3:35 PM Melanie Plageman
wrote:
> Any inserting transaction which aborts after heap_page_prune()'s
> visibility check will now be of no concern to lazy_scan_prune(). Since
> we don't do the visibility check again, we won't find the tuple
> HEAPTUPLE_DEAD and thus won't have
On Thu, Aug 31, 2023 at 5:39 AM David Geier wrote:
> Regarding the 2nd patch (disclaimer: I'm not too familiar with that area
> of the code): I don't completely understand why the retry loop is not
> needed anymore and how you now detect/handle the possible race
> condition? It can still happen th
On Thu, Aug 31, 2023 at 2:03 PM Robert Haas wrote:
>
> I have a few suggestions:
>
> - Rather than removing the rather large comment block at the top of
> lazy_scan_prune() I'd like to see it rewritten to explain how we now
> deal with the problem. I'd suggest leaving the first paragraph ("Prior
>
On Mon, Aug 28, 2023 at 7:49 PM Melanie Plageman
wrote:
> While working on a set of patches to combine the freeze and visibility
> map WAL records into the prune record, I wrote the attached patches
> reusing the tuple visibility information collected in heap_page_prune()
> back in lazy_scan_prune
Hi Melanie,
On 8/31/23 02:59, Melanie Plageman wrote:
I created a large table and then updated a tuple on every page in the
relation and vacuumed it. I saw a consistent slight improvement in
vacuum execution time. I profiled a bit with perf stat as well. The
difference is relatively small for th
> On Tue, Aug 29, 2023 at 5:07 AM David Geier wrote:
> > Could you measure any performance difference?
> >
> > If so could you provide your test case?
>
> I created a large table and then updated a tuple on every page in the
> relation and vacuumed it. I saw a consistent slight improvement in
> va
Hi David,
Thanks for taking a look!
On Tue, Aug 29, 2023 at 5:07 AM David Geier wrote:
>
> Hi Melanie,
>
> On 8/29/23 01:49, Melanie Plageman wrote:
> > While working on a set of patches to combine the freeze and visibility
> > map WAL records into the prune record, I wrote the attached patches
>
Hi Melanie,
On 8/29/23 01:49, Melanie Plageman wrote:
While working on a set of patches to combine the freeze and visibility
map WAL records into the prune record, I wrote the attached patches
reusing the tuple visibility information collected in heap_page_prune()
back in lazy_scan_prune().
hea
While working on a set of patches to combine the freeze and visibility
map WAL records into the prune record, I wrote the attached patches
reusing the tuple visibility information collected in heap_page_prune()
back in lazy_scan_prune().
heap_page_prune() collects the HTSV_Result for every tuple o
25 matches
Mail list logo
