On Thu, Mar 16, 2023 at 2:19 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > On Wed, Mar 15, 2023 at 12:20 PM Michael Paquier <mich...@paquier.xyz> wrote: > > I am not sure to get the concern here. As long as one is smart enough > > with SQL, there is no need to perform a double scan of the contents of > > pg_wal with a large scan on the start LSN. If one wishes to only > > extract some block for a given record type, or for a filter of your > > choice, it is possible to use a LATERAL on pg_get_wal_block_info(), > > say: > > SELECT r.start_lsn, b.blockid > > FROM pg_get_wal_records_info('0/01000028', '0/1911AA8') AS r, > > LATERAL pg_get_wal_block_info(start_lsn, end_lsn) as b > > WHERE r.resource_manager = 'Heap2'; > > > > This will extract the block information that you'd want for a given > > record type.
The same information *already* appears in pg_get_wal_records_info()'s block_ref output! Why should the user be expected to use a LATERAL join (or any type of join) to get _the same information_, just in a usable form? > IIUC, the concern raised so far in this thread is not just on the > performance of JOIN queries to get both block info and record level > info, but on ease of using pg_walinspect functions. If > pg_get_wal_block_info emits the record level information too (which > turns out to be 50 LOC more), one doesn't have to be expert at writing > JOIN queries or such, but just can run the function, which actually > takes way less time (3sec) to scan the same 5mn WAL records [3]. That's exactly my concern, yes. As you say, it's not just the performance aspect. Requiring users to write a needlessly ornamental query is actively misleading. It suggests that block_ref is distinct information from the blocks output by pg_get_wal_block_info(). -- Peter Geoghegan