Re: Add pg_walinspect function with block info columns
От | Peter Geoghegan |
---|---|
Тема | Re: Add pg_walinspect function with block info columns |
Дата | |
Msg-id | CAH2-Wz=bj1zOEgK8GU-hqUUqMa+B=U83w525gnT3Wt6WbmsHYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add pg_walinspect function with block info columns (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On Thu, Mar 30, 2023 at 2:41 PM Peter Geoghegan <pg@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
В списке pgsql-hackers по дате отправления: