From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Pavan Deolasee" <pavan(at)enterprisedb(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Heap page diagnostic/test functions (WIP) |
Date: | 2007-03-06 15:09:37 |
Message-ID: | 4470.1173193777@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
>> I'll return the infomasks directly, for you to manipulate.
>>
>> Not happy with that, but open to suggestions.
> Well the alternative would be a long list of boolean columns which would make
> the output kind of long.
> Perhaps a function pg_decode_infomask(varbit) which returns a ROW of booleans
> with appropriate names would be a good compromise. If you want it you could
> use it in your query.
This is pointless --- the function is already intended only for
debugging considerations, and anyone who needs it can be assumed capable
of ANDing with a bitmask or whatever he needs to do to inspect the
values. I don't see anyone asking for pretty display of cmin, say,
and yet that's certainly not that easy to interpret either.
As for masks plural, I'd be inclined to merge them into one 32-bit
result --- the distinction between flag bits in infomask and infomask2
is at this point entirely historical.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shane Ambler | 2007-03-06 16:13:39 | Re: Auto creation of Partitions |
Previous Message | Tom Lane | 2007-03-06 15:02:34 | Re: Aggressive freezing in lazy-vacuum |