>
> Are you implementing a new index AM or a new table AM? Discarding data
> based on something like a relevance score doesn't seem like something
> that either API provides for. Indexes in Postgres can be lossy, but
> that in itself doesn't change the result of queries.
>
(Sorry if this doesn't q
Thank you. Does this mean I can implement the index AM and return TIDs
without having to worry about transactions at all?
Also, as far as I can tell, the only way that TIDs are removed from the
index is in ambulkdelete(). Is this accurate? Does that mean that my index
will be returning TIDs for de
On Mon, Jul 19, 2021 at 7:20 PM Chris Cleveland
wrote:
> Thank you. Does this mean I can implement the index AM and return TIDs
> without having to worry about transactions at all?
Yes. That's the upside of the design -- it makes it easy to add new
transactional index AMs. Which is one reason wh
On Mon, Jul 19, 2021 at 4:31 PM Chris Cleveland
wrote:
> I'm confused on how to handle transactions and visibility.
In Postgres, indexes are not considered to be part of the logical
database. They're just data structures that point to TIDs in the
table. To an index, each TID is just another objec
Noob here.
I'm trying to implement a new type of index access method. I don't think I
can use the built-in storage manager and buffer manager efficiently because
files with 8k blocks aren't going to work. I really need to implement a
log-structured file.
I'm confused on how to handle transactions
