| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | michael(at)paquier(dot)xyz, 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-27 22:38:23 |
| Message-ID: | CAH2-WznQ67q62+twx729ZCFeFJ5GN0zLkyMEfsuad+XV9JFFLg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Mar 26, 2023 at 8:41 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > I'd still put the LSN data before the three OIDs for consistency with
> > the structures, though my opinion does not seem to count much..
>
> I agree with Michael on this point. Also, although it may not be
> significant for SQL, the rows are output in lsn order from the
> function.
I guess that it makes sense to have the LSN data first, but to have
the other columns after that. I certainly don't dislike that approach.
I just noticed is that "forkname" appears towards the end among
declared output parameters, even in Bharath's v6. I think that it
should be after "relblocknumber" instead, because it is conceptually
part of the "composite primary key", and so belongs right next to
"relblocknumber". I failed to mention this detail upthread, I think.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-03-27 22:38:25 | Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry |
| Previous Message | gkokolatos | 2023-03-27 22:34:52 | Re: Add LZ4 compression in pg_dump |