Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id CAH2-WzkuoPbgX+6nzadfh1a6F5C0+qKLmNEyvhijnpB=5c17Lg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Avoiding smgrimmedsync() during nbtree index builds
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Simplify backend terminate and wait logic in postgres_fdw test