Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row
Date: 2022-09-12 17:58:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com> writes:
> Attached is the rebased version of the patch
> (pageinspect_btree_multipagestats_03.patch) for the master branch.

I looked through this and cleaned up the code a little (attached).
There are still some issues before it could be considered committable:

1. Where's the documentation update?

2. As this stands, there's no nice way to ask for "all the pages".
If you specify a page count that's even one too large, you get an
error. I think there's room for an easier-to-use way to do that.
We could say that the thing just silently stops at the last page,
so that you just need to write a large page count. Or maybe it'd
be better to define a zero or negative page count as "all the rest",
while still insisting that a positive count refer to real pages.

3. I think it's highly likely that the new test case is not portable.
In particular a machine with MAXALIGN 4 would be likely to put a
different number of tuples per page, or do the page split differently
so that the page with fewer index tuples isn't page 3. Unfortunately
I don't seem to have a working setup like that right at the moment
to verify; but I'd counsel trying this inside a VM or something to
see if it's actually likely to survive on the buildfarm. I'm not
sure, but making the indexed column be int8 instead of int4 might
reduce the risks here.

regards, tom lane

Attachment Content-Type Size
pageinspect_btree_multipagestats-v4.patch text/x-diff 15.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-09-12 17:59:36 Re: Convert *GetDatum() and DatumGet*() macros to inline functions
Previous Message Andrey Borodin 2022-09-12 17:47:36 Re: pg_stat_statements locking