On Thu, Mar 30, 2023 at 2:41 PM Peter Geoghegan <p...@bowt.ie> wrote:
> pg@regression:5432 [1402115]=# SELECT
> count(*)
> FROM
> pg_get_wal_block_info ('0/10E9D80', 'FFFFFFFF/FFFFFFFF', true);
> ┌─[ RECORD 1 ]───────┐
> │ count │ 17,031,979 │
> └───────┴────────────┘
>
> Time: 15235.499 ms (00:15.235)
>
> This time is also typical of what I saw. The variance was fairly low,
> so I won't bother describing it.
If I rerun the same test case with pg_get_wal_records_info (same WAL
records, same system) then I find that it takes about 16 and a half
seconds. So my patch makes pg_get_wal_block_info a little bit faster
than pg_get_wal_records_info for this test case, and likely many
interesting cases (assuming that the user opts out of fetching
block_data and block_fpi_data values when running
pg_get_wal_block_info, per the patch).
This result closely matches what I was expecting. We're doing almost
the same amount of work when each function is called, so naturally the
runtime almost matches. Note that pg_get_wal_records_info does
slightly *more* work here, since it alone must output rows for commit
records. Unlike pg_get_wal_block_info, which (by design) never outputs
rows for WAL records that lack block references.
--
Peter Geoghegan
