On Fri, Aug 2, 2024 at 8:11 AM Masahiko Sawada wrote:
>
> On Wed, Jul 31, 2024 at 11:27 PM Anthonin Bonnefoy
> wrote:
> >
> > On Wed, Jul 31, 2024 at 9:36 PM Masahiko Sawada
> > wrote:
> > > Meanwhile, I think we can push 0001 and 0002 patches since they are in
> > > good shape. I've updated co
On Wed, Jul 31, 2024 at 11:27 PM Anthonin Bonnefoy
wrote:
>
> On Wed, Jul 31, 2024 at 9:36 PM Masahiko Sawada wrote:
> > Meanwhile, I think we can push 0001 and 0002 patches since they are in
> > good shape. I've updated commit messages to them and slightly changed
> > 0002 patch to write "finish
On Wed, Jul 31, 2024 at 9:36 PM Masahiko Sawada wrote:
> Meanwhile, I think we can push 0001 and 0002 patches since they are in
> good shape. I've updated commit messages to them and slightly changed
> 0002 patch to write "finished analyzing of table \"%s.%s.%s\" instead
> of "analyze of table \"
On Wed, Jul 31, 2024 at 12:03 AM Anthonin Bonnefoy
wrote:
>
> On Tue, Jul 30, 2024 at 9:21 AM Anthonin Bonnefoy
> wrote:
> > A possible change would be to pass an inh flag when an acquirefunc is
> > called from acquire_inherited_sample_rows. The acquirefunc could then
> > use an alternative log f
On Tue, Jul 30, 2024 at 9:21 AM Anthonin Bonnefoy
wrote:
> A possible change would be to pass an inh flag when an acquirefunc is
> called from acquire_inherited_sample_rows. The acquirefunc could then
> use an alternative log format to append to logbuf. This way, we could
> have a more compact for
Hi,
On Tue, Jul 30, 2024 at 1:13 AM Masahiko Sawada wrote:
> I have one comment on 0001 patch:
> The comment should also be updated or removed.
Ok, I've removed the comment.
> However, as the above comment says, delay_in_ms can have a duration up
> to 25 days. I guess it would not be a problem
Hi,
On Mon, Jul 29, 2024 at 12:12 AM Anthonin Bonnefoy
wrote:
>
> On Sat, Jul 27, 2024 at 12:35 AM Masahiko Sawada
> wrote:
> > An alternative idea would
> > be to pass StringInfo to AcquireSampleRowsFunc() so that callback can
> > write its messages there. This is somewhat similar to what we d
On Sat, Jul 27, 2024 at 12:35 AM Masahiko Sawada wrote:
> An alternative idea would
> be to pass StringInfo to AcquireSampleRowsFunc() so that callback can
> write its messages there. This is somewhat similar to what we do in
> the EXPLAIN command (cf, ExplainPropertyText() etc). It could be too
>
On Wed, Jul 24, 2024 at 1:58 AM Anthonin Bonnefoy
wrote:
>
> On Mon, Jul 22, 2024 at 10:59 PM Masahiko Sawada
> wrote:
> > The first line would vary depending on whether an autovacuum worker or
> > not. And the above suggestion includes a change of term "row" to
> > "tuple" for better consistenc
On Mon, Jul 22, 2024 at 10:59 PM Masahiko Sawada wrote:
> The first line would vary depending on whether an autovacuum worker or
> not. And the above suggestion includes a change of term "row" to
> "tuple" for better consistency with VACUUM VERBOSE outputs. I think it
> would be great if autoanaly
On Mon, Jul 8, 2024 at 2:35 AM Anthonin Bonnefoy
wrote:
>
> Hi,
>
> Thanks for the review, I've updated the patches with the suggestions:
> - moved renaming of misses to reads to the first patch
> - added intermediate variables for total blks usage
>
Thank you for working on this. 0001 patch look
Hi,
Thanks for the review, I've updated the patches with the suggestions:
- moved renaming of misses to reads to the first patch
- added intermediate variables for total blks usage
I've also done some additional tests using the provided
vacuum_analyze_buffer_usage.sql script. It relies on
pg_stat
I wrote:
>
> I suggest assigning values
> bufferusage.shared_blks_read + bufferusage.local_blks_read
> and
> bufferusage.shared_blks_dirtied + bufferusage.local_blks_dirtied
> to new variables and using them. This would keep the changed lines within
> the 80 symbols limit, and make the code more r
Hi Anthonin,
I suggest assigning values
bufferusage.shared_blks_read + bufferusage.local_blks_read
and
bufferusage.shared_blks_dirtied + bufferusage.local_blks_dirtied
to new variables and using them. This would keep the changed lines within
the 80 symbols limit, and make the code more readable ov
Thanks for having a look.
On Fri, May 10, 2024 at 12:40 PM Michael Paquier
wrote:
> This needs some runtime check to make sure that the calculations
> are consistent before and after the fact (cannot do that now).
>
Yeah, testing this is also a bit painful as buffer usage of analyze is only
disp
On Fri, May 10, 2024 at 10:54:07AM +0200, Anthonin Bonnefoy wrote:
> This patch replaces those Vacuum specific variables by pgBufferUsage
> in analyze. This makes VacuumPage{Hit,Miss,Dirty} unused and removable.
> This commit removes both their calls in bufmgr and their declarations.
Hmm, yeah, it
Hi,
Analyze logs within autovacuum uses specific variables
VacuumPage{Hit,Miss,Dirty} to track the buffer usage count. However,
pgBufferUsage already provides block usage tracking and handles more cases
(temporary tables, parallel workers...).
Those variables were only used in two places, block u
17 matches
Mail list logo
