On Mon, Aug 22, 2016 at 9:44 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote: > Please let me know your thoughts on this.
Since custom AMs have been introduced, I have kept that in a corner of my mind and thought about it a bit. And while the goal of this patch is clearly worth it, I don't think that the page masking interface is clear at all. For example, your patch completely ignores contrib/bloom, and we surely want to do something about it. The idea would be to add a page masking routine in IndexAmRoutine and heap to be able to perform page masking operations directly with that. This would allow as well one to be able to perform page masking for bloom or any custom access method, and this will allow this sanity check to be more generic as well. Another pin-point is: given a certain page, how do we identify of which type it is? One possibility would be again to extend the AM handler with some kind of is_self function with a prototype like that: bool handler->is_self(Page); If the page is of the type of the handler, this returns true, and false otherwise. Still here performance would suck. At the end, what we want is a clean interface, and more thoughts into it. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
