On 2020-Jul-10, Tomas Vondra wrote:
> > postgres(1:12801)=# select * from brin_page_items(get_raw_page('mul',
> > 2), 'mul');
> > -[ RECORD 1
> > ]----------------------------------------------------------------------------------------------------------------------
> > -----------------------------------------------------------------------------------------------------------------------------------
> > ----------------------------
> > itemoffset | 1
> > blknum | 0
> > attnum | 1
> > allnulls | f
> > hasnulls | f
> > placeholder | f
> > value |
> > {\x010000001b0000002000000001000000e5700000e6700000e7700000e8700000e9700000ea700000eb700000ec700000ed700000ee700000ef
> > 700000f0700000f1700000f2700000f3700000f4700000f5700000f6700000f7700000f8700000f9700000fa700000fb700000fc700000fd700000fe700000ff700
> > 00000710000}
>
> Hmm. I'm not sure we can do much better, without making the function
> much more complicated. I mean, even with regular BRIN indexes we don't
> really know if the value is plain min/max, right?
Maybe we can try to handle this with some other function that interprets
the bytea in 'value' and returns a user-readable text. I think it'd
have to be a superuser-only function, because otherwise you could easily
cause a crash by passing a value of a different opclass. But since this
seems a developer-only thing, that restriction seems fine to me.
(I don't know what's a good way to represent a bloom filter, mind.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
