Re: logtape.c stats don't account for unused "prefetched" block numbers
От | Peter Geoghegan |
---|---|
Тема | Re: logtape.c stats don't account for unused "prefetched" block numbers |
Дата | |
Msg-id | CAH2-WznKzX117FE=Aps1vvZjrLK2CFwp7idnLyboA8mwfgN2og@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logtape.c stats don't account for unused "prefetched" block numbers (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: logtape.c stats don't account for unused "prefetched" block numbers
|
Список | 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 по дате отправления: