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

From Peter Geoghegan
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id CAH2-WznYBnMKgjLQfT_C38=wcMyWzAWFid3g76t0JdByuZ6skg@mail.gmail.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG in container w/ pid namespace is init, process exits cause restart
Next
From: Alvaro Herrera
Date:
Subject: Re: PG in container w/ pid namespace is init, process exits cause restart