Re: MaxOffsetNumber for Table AMs

On Mon, May 3, 2021 at 2:03 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Another point: the idea of supporting only some kinds of indexes
> doesn't mix well with partitioning. If you declare an index on the
> parent, we should do something reasonable if one partition's table AM
> doesn't support that index AM.

Sure, but it either makes sense for the columnar table AM to support
bitmap scans (or some analogous type of scan that works only slightly
differently) or it doesn't. It's not at all clear which it is right now.

If it makes sense then it will of course be necessary to describe what
"bitmap scan" actually means with the columnar storage table AM (plus
you'll still need to make some in-core changes to places like
tidbitmap.c). OTOH if it doesn't make sense then that's that -- it's
going to be a bit annoying in the partitioning scenario you describe,
but some things are bound to be *inherently* impossible, so it can't be
helped.

It seems senseless to *require* table AMs to support something like a
bitmap scan. I don't think it's a coincidence that GIN is the index AM
that looks like it presents at least 2 problems for the columnar table
AM. To me this suggests that this will need a much higher level
discussion.

--
Peter Geoghegan