On Tue, Mar 28, 2023 at 11:15:17AM -0700, Peter Geoghegan wrote: > On Mon, Mar 27, 2023 at 7:47 PM Bharath Rupireddy > <bharath.rupireddyforpostg...@gmail.com> wrote: >> Hm, agreed. Changed in the attached v7-0002 patch. We can as well >> write a case statement in the create function SQL to output forkname >> instead forknumber, but I'd stop doing that to keep in sync with >> pg_buffercache. > > I just don't see much value in any textual representation of fork > name, however generated. In practice it's just not adding very much > useful information. It is mostly useful as a way of filtering block > references, which makes simple integers more natural.
I disagree with this argument. Personally, I have a *much* better experience with textual representation because there is no need to cross-check the internals of the code in case you don't remember what a given number means in an enum or in a set of bits, especially if you're in a hurry of looking at a production or customer deployment. In short, it makes for less mistakes because you don't have to think about some extra mapping between some integers and what they actually mean through text. The clauses you'd apply for a group by on the forks, or for a filter with IN clauses don't change, they're just made easier to understand for the common user, and that includes experienced people. We'd better think about that like the text[] arrays we use for the flag values, like the FPI flags, or why we've introduced text[] for the HEAP_* flags in the heap functions of pageinspect. There's even more consistency with pageinspect in using a fork name, where we can pass down a fork name to get a raw page. -- Michael
signature.asc
Description: PGP signature