Re: MaxOffsetNumber for Table AMs - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id CAH2-WzkuoPbgX+6nzadfh1a6F5C0+qKLmNEyvhijnpB=5c17Lg@mail.gmail.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: MaxOffsetNumber for Table AMs
Re: MaxOffsetNumber for Table AMs
List pgsql-hackers
On Mon, May 3, 2021 at 2:03 PM Jeff Davis <pgsql@j-davis.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



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Avoiding smgrimmedsync() during nbtree index builds
Next
From: Tom Lane
Date:
Subject: Re: Simplify backend terminate and wait logic in postgres_fdw test