|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>|
|Subject:||Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|