On Tue, Mar 14, 2023 at 6:57 PM Peter Geoghegan <p...@bowt.ie> wrote: > > On Tue, Mar 14, 2023 at 3:34 PM Melanie Plageman > <melanieplage...@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
