Re: logtape.c stats don't account for unused "prefetched" block numbers - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: logtape.c stats don't account for unused "prefetched" block numbers
Date
Msg-id aa34752723c4dd0bc97d066316f1e764e85c935c.camel@j-davis.com
Whole thread Raw
In response to Re: logtape.c stats don't account for unused "prefetched" block numbers  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: logtape.c stats don't account for unused "prefetched" block numbers
List pgsql-hackers
On Mon, 2020-09-14 at 14:24 -0700, Peter Geoghegan wrote:
> On Fri, Sep 11, 2020 at 6:37 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > It would be awkward if we just used nBlocksWritten within
> > LogicalTapeSetBlocks() in the case where we didn't preallocate (or
> > in
> > all cases). Not entirely sure what to do about that just yet.
> 
> I guess that that's the logical thing to do, as in the attached
> patch.

Hi Peter,

In the comment in the patch, you say:

"In practice this probably doesn't matter because we'll be called after
the flush anyway, but be tidy."

By which I assume you mean that LogicalTapeRewindForRead() will be
called before LogicalTapeSetBlocks().

If that's the intention of LogicalTapeSetBlocks(), should we just make
it a requirement that there are no open write buffers for any tapes
when it's called? Then we could just use nBlocksWritten in both cases,
right?

(Aside: HashAgg calls it before LogicalTapeRewindForRead(). That might
be a mistake in HashAgg where it will keep the write buffers around
longer than necessary. If I recall correctly, it was my intention to
rewind for reading immediately after the batch was finished, which is
why I made the read buffer lazily-allocated.)

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Division in dynahash.c due to HASH_FFACTOR
Next
From: Alvaro Herrera
Date:
Subject: Re: logtape.c stats don't account for unused "prefetched" block numbers