Re: Add pg_walinspect function with block info columns

On Tue, Mar 21, 2023 at 11:33 PM Michael Paquier <michael@paquier.xyz> wrote:
> > The new pg_get_wal_block_info outputs columns in an order that doesn't
> > seem like the most useful possible order to me. This gives us another
> > reason to have separate GetWALRecordInfo and GetWALBlockInfo utility
> > functions rather than sharing logic for building output tuples.
> >
> > Specifically, I think that pg_get_wal_block_info should ouput the
> > "primary key" columns first:
> >
> > reltablespace, reldatabase, relfilenode, blockid, start_lsn, end_lsn
>
> It seems to me that this is up to the one using this SQL?

If you see it that way, then why does it matter what I may want to do
with the declared order?

> I am not
> sure to follow why this is important.  For the cases you have poked
> at, I guess it is, but is strikes me that it is just natural to shape
> that to  match the C structures we use for the WAL records
> themselves, so the other way around.

I don't feel very strongly about it, but it seems better to highlight
the difference that exists between this and pg_get_wal_records_info.

> Hence, it seems to me that 0002 has the order pretty much right.
> What's the point in adding the description, by the way?  Only
> consistency with the other function?  Is that really useful if you
> want to apply more quals when retrieving some block data?

I don't understand. It's useful to include the description for the
same reason as it's useful to include it in pg_get_wal_records_info.
Why wouldn't it be useful?

Most individual records that have any block_ref blocks have exactly
one. Most individual WAL records are very simple record types. So
pg_get_wal_block_info just isn't going to look that different to
pg_get_wal_records_info, once they share most of the same columns. The
way that pg_get_wal_block_info disaggregates on block won't make the
output look all that different. So each distinct "description" will
usually only appear once in pg_get_wal_block_info anyway.

-- 
Peter Geoghegan