Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id CAH2-WznYBnMKgjLQfT_C38=wcMyWzAWFid3g76t0JdByuZ6skg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers
On Mon, May 3, 2021 at 12:06 PM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> One could relatively easily disable bitmap scans on the table AM by
> not installing the relevant bitmap support functions on the registered
> TableAM structure, and thus not touch that problem.

I have no idea how much it'll hurt things if the column store table AM
supports no analogue of bitmap scans.

> Some indexes will
> then never be accessed due to the bitmap scan requirement of their
> IndexAM (gin, brin, bloom, to name a few), and as such won't make
> sense to create on that table, but that's about it I think.

Right. More formally: if this restriction is accepted by a table AM
(say the column store table AM), then any index AM with amgettuple set
to NULL cannot ever be used (it should probably be treated as an error
condition at CREATE INDEX time).

If this really is the best path forward (again, no idea if that's
true) then that would conveniently make it pretty easy to solve the
GIN posting list issue raised by Jeff. It just wouldn't matter -- GIN
indexes cannot be used with the column store anyway.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PG in container w/ pid namespace is init, process exits cause restart
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: PG in container w/ pid namespace is init, process exits cause restart