From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, melanieplageman(at)gmail(dot)com, boekewurm+postgres(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add pg_walinspect function with block info columns |
Date: | 2023-03-23 00:13:03 |
Message-ID: | CAH2-Wz=5yYDmEz5p4qrc9FhPat5VxGkNcKNN_OXRFkyZ4dWBsQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 21, 2023 at 11:33 PM Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-03-23 00:14:08 | Re: Add n_tup_newpage_upd to pg_stat table views |
Previous Message | Michael Paquier | 2023-03-23 00:09:37 | Re: Remove nonmeaningful prefixes in PgStat_* fields |