From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(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-14 22:56:50 |
Message-ID: | CAH2-Wzm-LaF3tQxzW=S16kOJZEivuzGGyz56wKTz+SnK2oKwgQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 14, 2023 at 3:34 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> After patching master to add in the columns from
> pg_get_wal_records_info() which are not returned by
> pg_get_wal_block_info() (except block_ref column of course), this query:
>
> SELECT COUNT(*) FROM pg_get_wal_block_info(:start_lsn, :end_lsn);
>
> took 467 ms.
>
> Perhaps this difference isn't important, but I found it noticeable.
This seems weird to me too. It's not so much the performance overhead
that bothers me (though that's not great either). It seems *illogical*
to me. The query you end up writing must do two passes over the WAL
records, but its structure almost suggests that it's necessary to do
two separate passes over distinct "streams".
Why doesn't it already work like this? Why do we need a separate
pg_get_wal_block_info() function at all?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Jones | 2023-03-14 22:57:22 | Re: [PATCH] Add pretty-printed XML output option |
Previous Message | Andres Freund | 2023-03-14 22:56:15 | Re: Track IO times in pg_stat_io |