| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add pg_walinspect function with block info columns |
| Date: | 2023-03-15 07:00:22 |
| Message-ID: | ZBFtBpJnJolMrRWq@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 15, 2023 at 12:13:56PM +0530, Bharath Rupireddy wrote:
> How about something like the attached? It adds the per-record columns
> to pg_get_wal_block_info() avoiding "possibly expensive" joins with
> pg_get_wal_records_info().
>
> With this, pg_get_wal_records_info() too will be useful for users
> scanning WAL at record level. That is to say that we can retain both
> pg_get_wal_records_info() and pg_get_wal_block_info().
FWIW, I am not convinced that there is any need to bloat more the
attributes of these functions, as filters for records could basically
touch all the fields returned by pg_get_wal_records_info(). What
about adding an example in the docs with the LATERAL query I mentioned
previously?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2023-03-15 07:10:17 | Re: Combine pg_walinspect till_end_of_wal functions with others |
| Previous Message | Michael Paquier | 2023-03-15 06:57:45 | Re: Combine pg_walinspect till_end_of_wal functions with others |