On Wed, Aug 25, 2021 at 5:23 PM Alvaro Herrera wrote:
> Ooh, this was illuminating -- thanks for explaining. TBH I would have
> been very confused if asked to explain what that log line meant; and now
> that I know what it means, I am even more convinced that we need to work
> harder at it :-)
>
On Fri, Aug 27, 2021 at 12:55 PM Stephen Frost wrote:
> > Okay. Plan is now to push these two patches together, later on. The
> > second patch concerns this separate track_io_timing issue. It's pretty
> > straightforward.
> >
> > (No change to the first patch in the series, relative to the v2 from
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Fri, Aug 27, 2021 at 12:30 PM Stephen Frost wrote:
> > I don't particularly care for that explain rule, ultimately, but it's
> > been around longer than I have and so I guess it wins. I'm fine with
> > always showing the read/write for VACU
On Fri, Aug 27, 2021 at 12:30 PM Stephen Frost wrote:
> I don't particularly care for that explain rule, ultimately, but it's
> been around longer than I have and so I guess it wins. I'm fine with
> always showing the read/write for VACUUM and ANALYZE.
>
> Including 'ms' and lower-casing 'Timings
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Fri, Aug 27, 2021 at 11:35 AM Stephen Frost wrote:
> > > BTW, I noticed one thing about the track_io_time stuff. Sometimes it
> > > looks like this:
> > >
> > > I/O timings:
> > >
> > > i.e., it doesn't show anything at all after the
On Fri, Aug 27, 2021 at 11:35 AM Stephen Frost wrote:
> > BTW, I noticed one thing about the track_io_time stuff. Sometimes it
> > looks like this:
> >
> > I/O timings:
> >
> > i.e., it doesn't show anything at all after the colon.
> Reporting zeros seems
> valuable to me in that it shows
On Thu, Aug 26, 2021 at 10:28 PM Peter Geoghegan wrote:
> I'll commit this in a day or two, backpatching to 14. Barring any objections.
Actually, we also need to make the corresponding lines for ANALYZE
follow the same convention -- those really should be consistent. As in
the attached revision.
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Wed, Aug 25, 2021 at 2:07 PM Stephen Frost wrote:
> > I generally like the idea though I'm not sure about changing things in
> > v13 as there's likely code out there that's already parsing that data
> > and it might suddenly break if this wa
On Wed, Aug 25, 2021 at 2:07 PM Stephen Frost wrote:
> I generally like the idea though I'm not sure about changing things in
> v13 as there's likely code out there that's already parsing that data
> and it might suddenly break if this was changed.
Agreed -- I won't backpatch anything to v13.
>
On Wed, Aug 25, 2021 at 5:02 PM Peter Geoghegan wrote:
> > I like it better than the current layout, so +1.
>
> This seems like a release housekeeping task to me. I'll come up with
> a patch targeting 14 and master in a few days.
Here is a patch that outputs log_autovacuum's lines in this order:
On Wed, Aug 25, 2021 at 08:23:04PM -0400, Alvaro Herrera wrote:
> On 2021-Aug-25, Peter Geoghegan wrote:
>> This seems like a release housekeeping task to me. I'll come up with
>> a patch targeting 14 and master in a few days.
>
> Agreed, thanks.
Sorry for the late reply here. Indeed, I can see
On Wed, Aug 25, 2021 at 5:23 PM Alvaro Herrera wrote:
> > The question of whether or not we do an index scan (i.e. index
> > vacuuming) depends entirely on the number of LP_DEAD items that heap
> > pruning left behind in the table structure. [...]
>
> Ooh, this was illuminating -- thanks for expla
On 2021-Aug-25, Peter Geoghegan wrote:
> On Wed, Aug 25, 2021 at 2:06 PM Alvaro Herrera
> wrote:
> > I like it better than the current layout, so +1.
>
> This seems like a release housekeeping task to me. I'll come up with
> a patch targeting 14 and master in a few days.
Agreed, thanks.
> T
On Wed, Aug 25, 2021 at 2:06 PM Alvaro Herrera wrote:
> You mean:
>
> LOG: automatic vacuum of table "regression.public.bmsql_order_line": index
> scans: 1
> pages: 0 removed, 8810377 remain, 0 skipped due to pins, 3044924 frozen
> tuples: 16819838 removed, 576364686 remain, 2207444 are dead but
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Wed, Aug 25, 2021 at 11:42 AM Nikolay Samokhvalov
> wrote:
> > The last two lines are also "*** usage" -- shouldn't the buffer numbers be
> > next to them?
>
> I agree that that would be better still -- but all the "usage" stuff
> together
On 2021-Aug-25, Peter Geoghegan wrote:
> That way the overall structure starts with details of the physical
> data structures (the table and its indexes), then goes into buffers
>
> 1. Heap pages
> 2. Heap tuples
> 3. Index stuff
> 4. I/O timings (only when track_io_timing is on)
> 5. avg read ra
On Wed, Aug 25, 2021 at 1:33 PM Stephen Frost wrote:
> I don't have any particular issue with moving them.
What do you think of the plan I just outlined to Nikolay?
--
Peter Geoghegan
On Wed, Aug 25, 2021 at 11:42 AM Nikolay Samokhvalov
wrote:
> The last two lines are also "*** usage" -- shouldn't the buffer numbers be
> next to them?
I agree that that would be better still -- but all the "usage" stuff
together in one block.
And that leads me to another observation: The trac
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> log_autovacuum output looks like this (as of Postgres 14):
>
> LOG: automatic vacuum of table "regression.public.bmsql_order_line":
> index scans: 1
> pages: 0 removed, 8810377 remain, 0 skipped due to pins, 3044924 frozen
> tuples: 16819838 r
On Wed, Aug 25, 2021 at 10:34 AM Peter Geoghegan wrote:
> It would be a lot clearer if the "buffer usage" line was simply moved
> down. I think that it should appear after the lines that are specific
> to the table's indexes -- just before the "avg read rate" line. That
> way we'd group the buffe
20 matches
Mail list logo
