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

From Peter Geoghegan
Subject Re: logtape.c stats don't account for unused "prefetched" block numbers
Date
Msg-id CAH2-WznKzX117FE=Aps1vvZjrLK2CFwp7idnLyboA8mwfgN2og@mail.gmail.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 Thu, Sep 10, 2020 at 6:42 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Obviously you must be wondering what the difference is, if it's not
> just the nHoleBlocks thing. nBlocksAllocated is not necessarily equal
> to nBlocksWritten (even when we ignore concatenation/nHoleBlocks), but
> it's almost always equal in practice (again, barring nHoleBlocks !=
> 0).

Noticing that you pushed a commit to disable preallocation for
external sorts, I tried to determine if there are any remaining
problem. As far as I can tell there are no remaining problems --
evidently the loop logic in ltsWriteBlock() both performs its original
task (per commit 7ac4a389a7d), as well as the new task of
preallocation for its HashAggs-that-spill caller.

There is a case in the regression tests (including the Postgres 12
regression tests) that relies on the loop within ltsWriteBlock() for
an external sort. FWIW, that happens in the "cluster clstr_tst4 using
cluster_sort" cluster tuplesort. The trace_sort output (and the temp
file size) is now consistent across versions 12 and 13.

I'll probably close out this open item tomorrow. I need to think about
it some more, but right now everything looks good. I think I'll
probably end up pushing a commit with more explanatory comments.

Thank you
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: 回复:how to create index concurrently on partitioned table
Next
From: Michael Paquier
Date:
Subject: Re: 回复:how to create index concurrently on partitioned table