On Thu, Mar 30, 2023 at 2:41 PM Peter Geoghegan <p...@bowt.ie> wrote: > There is still an outstanding question around the overhead of > outputting FPIs and even block data from pg_get_wal_block_info(). At > one point Melanie suggested that we'd need to do something about that, > and I tend to agree. Attached patch provides an optional parameter > that will make pg_get_wal_block_info return NULLs for both block_data > and block_fpi_data, no matter whether or not there is something to > show. Note that this only affects those two bytea columns; we'll still > show everything else, including valid block_data_length and > block_fpi_length values (so the metadata describing the on-disk size > of block_data and block_fpi_data is unaffected).
I pushed this patch just now. Except that the final commited version had the "suppress_block_data" output parameter name flipped. It was inverted and renamed to "show_data" (and made "DEFAULT true"). This is closer to how the pg_stat_statements() function handles a similar issue with overly large query texts. I'm very happy with the end result of the work on this thread. It works a lot better for the sorts of queries I am interested in. Thanks to all involved, particularly Bharath. -- Peter Geoghegan
