Re: Add pg_walinspect function with block info columns - Mailing list pgsql-hackers

On Tue, Mar 14, 2023 at 6:57 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Tue, Mar 14, 2023 at 3:34 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> > After patching master to add in the columns from
> > pg_get_wal_records_info() which are not returned by
> > pg_get_wal_block_info() (except block_ref column of course), this query:
> >
> >   SELECT COUNT(*) FROM pg_get_wal_block_info(:start_lsn, :end_lsn);
> >
> > took 467 ms.
> >
> > Perhaps this difference isn't important, but I found it noticeable.
>
> This seems weird to me too. It's not so much the performance overhead
> that bothers me (though that's not great either). It seems *illogical*
> to me. The query you end up writing must do two passes over the WAL
> records, but its structure almost suggests that it's necessary to do
> two separate passes over distinct "streams".
>
> Why doesn't it already work like this? Why do we need a separate
> pg_get_wal_block_info() function at all?

Well, I think if you only care about the WAL record-level information
and not the block-level information, having the WAL record information
denormalized like that with all the block information would be a
nuisance.

But, perhaps you are suggesting a parameter to pg_get_wal_records_info()
like "with_block_info" or something, which produces the full
denormalized block + record output?

- Melanie