On Mon, Dec 16, 2024 at 7:14 PM Melanie Plageman
wrote:
>
> On Wed, Dec 11, 2024 at 2:18 PM Masahiko Sawada wrote:
> >
> > I agree that it will be unimportant from Melanie's work in this area.
> > Also, I agree that if semi-aggressive vacuum has its own new logging
> > message about what it's don
On Thu, Dec 12, 2024 at 9:39 PM Tomas Vondra wrote:
>
> On 12/11/24 20:18, Masahiko Sawada wrote:
> >
> > ...
> >
> >> Here's an example to exercise the new log message:
> >>
> >> create table foo (a int, b int) with (autovacuum_enabled = false);
> >> insert into foo select generate_series(1,1000)
On Wed, Dec 11, 2024 at 2:18 PM Masahiko Sawada wrote:
>
> On Thu, Dec 5, 2024 at 4:32 PM Melanie Plageman
> wrote:
> >
> > On Mon, Dec 2, 2024 at 9:28 AM Robert Haas wrote:
> > >
> > >
> > > All that said, if you really want this broken out into three
> > > categories rather than two, I'm not o
Hi,
Thank you for working on this!
On Fri, 6 Dec 2024 at 03:32, Melanie Plageman wrote:
>
> Here's an example to exercise the new log message:
>
> create table foo (a int, b int) with (autovacuum_enabled = false);
> insert into foo select generate_series(1,1000), 1;
> delete from foo where a > 5
On 12/11/24 20:18, Masahiko Sawada wrote:
>
> ...
>
>> Here's an example to exercise the new log message:
>>
>> create table foo (a int, b int) with (autovacuum_enabled = false);
>> insert into foo select generate_series(1,1000), 1;
>> delete from foo where a > 500;
>> vacuum (verbose) foo;
>> -- v
On Thu, Dec 5, 2024 at 4:32 PM Melanie Plageman
wrote:
>
> On Mon, Dec 2, 2024 at 9:28 AM Robert Haas wrote:
> >
> > On Fri, Nov 29, 2024 at 2:46 PM Masahiko Sawada
> > wrote:
> > > Finally, in case where we have:
> > >
> > > visibility map: 1 pages set all-visible, 1 pages set all-froz
On Mon, Dec 2, 2024 at 9:28 AM Robert Haas wrote:
>
> On Fri, Nov 29, 2024 at 2:46 PM Masahiko Sawada wrote:
> > Finally, in case where we have:
> >
> > visibility map: 1 pages set all-visible, 1 pages set all-frozen.
> >
> > We can understand that 1 pages newly became all-frozen, but
On Fri, Nov 29, 2024 at 2:46 PM Masahiko Sawada wrote:
> Finally, in case where we have:
>
> visibility map: 1 pages set all-visible, 1 pages set all-frozen.
>
> We can understand that 1 pages newly became all-frozen, but have
> no idea how many pages became all-visible but not all-fro
On Wed, Nov 27, 2024 at 9:01 AM Robert Haas wrote:
>
> On Tue, Nov 26, 2024 at 8:38 PM Masahiko Sawada wrote:
> > > visibility map: 5 pages set all-visible, 4 pages set all-frozen.
> >
> > Which means that 5 pages were marked as only all-visible and 4 pages
> > were marked as all-frozen (and poss
On Tue, Nov 26, 2024 at 8:38 PM Masahiko Sawada wrote:
> > visibility map: 5 pages set all-visible, 4 pages set all-frozen.
>
> Which means that 5 pages were marked as only all-visible and 4 pages
> were marked as all-frozen (and possibly all-visible too). The total
> number of pages' whose VM sta
On Tue, Nov 26, 2024 at 12:37 PM Melanie Plageman
wrote:
>
> On Tue, Nov 26, 2024 at 1:55 PM Masahiko Sawada wrote:
> >
> > Just to be clear, do users want the number of updated VM bits or the
> > number of pages whose visibility information is updated? For example,
> >
> > > visibility map: 5 pa
On Tue, Nov 26, 2024 at 1:55 PM Masahiko Sawada wrote:
>
> Just to be clear, do users want the number of updated VM bits or the
> number of pages whose visibility information is updated? For example,
>
> > visibility map: 5 pages set all-visible, 4 pages set all-frozen.
>
> IIUC the above log can
On Thu, Nov 21, 2024 at 2:43 PM Melanie Plageman
wrote:
>
> On Fri, Nov 1, 2024 at 5:39 PM Masahiko Sawada wrote:
> >
> > I think we agreed with what the patches proposed by Melanie do, so
> > let's focus on these patches on this thread. We can add other
> > information later if we need.
>
> Than
Thanks for the review, Nitin! Attached v3 addresses your review feedback.
On Sat, Nov 2, 2024 at 7:05 AM Nitin Jadhav
wrote:
>
> 1.
> > + BlockNumber vm_page_freezes;/* # pages newly set all-frozen in VM */
> > + BlockNumber vm_page_visibles; /* # pages newly set all-visible in the
> >
On Fri, Nov 1, 2024 at 5:39 PM Masahiko Sawada wrote:
>
> I think we agreed with what the patches proposed by Melanie do, so
> let's focus on these patches on this thread. We can add other
> information later if we need.
Thanks for the feedback and input.
So, currently what I have is a line for u
1.
> + BlockNumber vm_page_freezes;/* # pages newly set all-frozen in VM */
> + BlockNumber vm_page_visibles; /* # pages newly set all-visible in the
> VM */
I believe renaming the variables to ‘vm_freeze_pages’ and
‘vm_visible_pages’ would enhance readability and ensure consistency
wit
On Fri, Nov 1, 2024 at 9:41 AM Robert Haas wrote:
>
> On Fri, Nov 1, 2024 at 12:23 PM Masahiko Sawada wrote:
> > Having "marked by this operation" twice seems to be redundant. How
> > about something like the output below?
> >
> > visibility map: %u pages set all-visible (%u pages total), %u page
On Fri, Nov 1, 2024 at 12:23 PM Masahiko Sawada wrote:
> Having "marked by this operation" twice seems to be redundant. How
> about something like the output below?
>
> visibility map: %u pages set all-visible (%u pages total), %u pages
> set all-frozen (%u pages total)
For me, the meaning of tha
On Fri, Nov 1, 2024 at 5:12 AM Alastair Turner wrote:
>
> On Thu, 31 Oct 2024 at 18:51, Melanie Plageman
> wrote:
>>
>>
>> Would it also be useful to have the number set all-visible? It seems
>> like if we added a new line prefixed with visibility map, it ought to
>> include all-visible and all-
On Thu, 31 Oct 2024 at 18:51, Melanie Plageman
wrote:
>
> Would it also be useful to have the number set all-visible? It seems
> like if we added a new line prefixed with visibility map, it ought to
> include all-visible and all-frozen then.
> Something like this:
> visibility map: %u pages set
Thanks for the review!
On Thu, Oct 31, 2024 at 2:13 PM Masahiko Sawada wrote:
>
>
> Some small suggestions:
>
> + vmbits = visibilitymap_set(vacrel->rel, blkno, buf,
> + InvalidXLogRecPtr,
> + vmbuffer, InvalidTra
On Thu, Oct 31, 2024 at 11:56 AM Alastair Turner wrote:
>
> For user consumption, to reduce the number of puzzled questions, I'd suggest
> adding a line to the log output of the form
>
> visibility map: %u pages set all frozen, up to %u may have been removed from
> the table
>
> rather than appe
On Wed, Oct 30, 2024 at 2:42 PM Melanie Plageman
wrote:
>
> Vacuum currently counts and logs the number of pages of a relation
> with newly frozen tuples. It does not count the number of pages newly
> set all-frozen in the visibility map.
>
> The number of pages set all-frozen in the visibility ma
On Thu, 31 Oct 2024 at 15:26, Melanie Plageman
wrote:
> On Thu, Oct 31, 2024 at 11:15 AM Peter Geoghegan wrote:
> >
> > On Thu, Oct 31, 2024 at 10:22 AM Melanie Plageman
> > wrote:
> > > It seems a better solution would be to find a way to document it or
> > > phrase it clearly in the log. It i
On Thu, Oct 31, 2024 at 12:02 PM Robert Haas wrote:
> I don't see it quite the same way. I agree that what users are really
> concerned about is the excessive number of unfrozen pages in the VM.
> But that's not the question here. The question is what should
> log_autovacuum_min_duration log. And
On Thu, Oct 31, 2024 at 11:15 AM Peter Geoghegan wrote:
> Probably not, but I don't think that it's worth worrying about. ISTM
> that it's inevitable that somebody might get confused whenever we
> expose implementation details such as these. This particular example
> doesn't seem particularly conc
On Thu, Oct 31, 2024 at 11:49 AM Peter Geoghegan wrote:
> The emphasis on the work that one particular VACUUM operation
> performed doesn't seem like the most relevant thing to users (I get
> why you'd care about it in the context of your work, though). What
> matters to users is that the overall
On Thu, Oct 31, 2024 at 11:26 AM Melanie Plageman
wrote:
> I'm biased because I want the count of pages newly set all-frozen in
> the VM for another patch. You think exposing the total number of
> all-frozen pages at the end of the vacuum is more useful to users?
The emphasis on the work that one
On Thu, Oct 31, 2024 at 11:15 AM Peter Geoghegan wrote:
>
> On Thu, Oct 31, 2024 at 10:22 AM Melanie Plageman
> wrote:
> > It seems a better solution would be to find a way to document it or
> > phrase it clearly in the log. It is true that these pages were set
> > all-frozen in the VM. It is jus
On Thu, Oct 31, 2024 at 10:22 AM Melanie Plageman
wrote:
> It seems a better solution would be to find a way to document it or
> phrase it clearly in the log. It is true that these pages were set
> all-frozen in the VM. It is just that some of them were later removed.
> And we don't know which one
Thanks for taking a look, Alastair!
On Thu, Oct 31, 2024 at 5:47 AM Alastair Turner wrote:
>
> The values returned in a case pages are removed (cases where the empty pages
> are at the end of the table) are a bit confusing.
>
> In an example similar to yours, but with a normal vacuum operation,
Hi Melanie
On Wed, 30 Oct 2024 at 21:42, Melanie Plageman
wrote:
> ...
>
The number of pages set all-frozen in the visibility map by a given
> vacuum can be useful when analyzing which normal vacuums reduce the
> number of pages future aggressive vacuum need to scan.
>
> Also, empty pages that a
Vacuum currently counts and logs the number of pages of a relation
with newly frozen tuples. It does not count the number of pages newly
set all-frozen in the visibility map.
The number of pages set all-frozen in the visibility map by a given
vacuum can be useful when analyzing which normal vacuum
33 matches
Mail list logo
