From: | Kirill Bychik <kirill(dot)bychik(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Subject: | Re: WAL usage calculation patch |
Date: | 2020-03-15 18:52:18 |
Message-ID: | CAB-hujoJ7dUcy=upG+3QOzrad0qWdCW+LkC10vSW2UNLVvhEbA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > On Thu, Mar 5, 2020 at 8:55 PM Kirill Bychik <kirill(dot)bychik(at)gmail(dot)com> wrote:
> > > > I wanted to keep the patch small and simple, and fit to practical
> > > > needs. This patch is supposed to provide tuning assistance, catching
> > > > an io heavy query in commit-bound situation.
> > > > Total WAL usage per DB can be assessed rather easily using other means.
> > > > Let's get this change into the codebase and then work on connecting
> > > > WAL usage to (auto)vacuum stats.
> > >
> > > I agree that having a view of the full activity is a way bigger scope,
> > > so it could be done later (and at this point in pg14), but I'm still
> > > hoping that we can get insight of other backend WAL activity, such as
> > > autovacuum, in pg13.
> >
> > How do you think this information should be exposed? Via the pg_stat_statement?
>
> That's unlikely, since autovacuum won't trigger any hook. I was
> thinking on some new view for pgstats, similarly to the example I
> showed previously. The implementation is straightforward, although
> pg_stat_database is maybe not the best choice here.
After extensive thinking and some code diving, I did not manage to
come up with a sane idea on how to expose data about autovacuum WAL
usage. Must be the flu.
> > Anyways, I believe this change could be bigger than FPI. I propose to
> > plan a separate patch for it, or even add it to the TODO after the
> > core patch of wal usage is merged.
>
> Just in case, if the problem is a lack of time, I'd be happy to help
> on that if needed. Otherwise, I'll definitely not try to block any
> progress for the feature as proposed.
Please feel free to work on any extension of this patch idea. I lack
both time and knowledge to do it all by myself.
> > Please expect a new patch version next week, with FPI counters added.
Please find attached patch version 003, with FP writes and minor
corrections. Hope i use attachment versioning as expected in this
group :)
Test had been reworked, and I believe it should be stable now, the
part which checks WAL is written and there is a correlation between
affected rows and WAL records. I still have no idea how to test
full-page writes against regular updates, it seems very unstable.
Please share ideas if any.
Thanks!
Attachment | Content-Type | Size |
---|---|---|
003.wal_stats.core.patch | text/x-patch | 12.7 KB |
003.wal_stats.ext.patch | text/x-patch | 21.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2020-03-15 19:09:52 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Previous Message | Pavel Stehule | 2020-03-15 18:23:36 | Re: proposal: new polymorphic types - commontype and commontypearray |