Accessing a row directly at a table in PostgreSQL by using the PostgreSQL's internal library I am writing a PostgreSQL extension using the C language. I would like to do the following tasks:


Store a set of rowids (or other row identifier, like ctid). Each rowid uniquely represents a row in its table.
Process this set and return other set of rowids
As a result, I want to access the tuples pointed by the returned rowids


For instance, I have a table with the rowids => {1, 2, ..., 10000}. Then, I have processed my algorithm, and as result I have the following rowids => {3, 100, 8394, 12}

However, I have some doubts:


What tuple identifier would be the best to be stored in the task 1? According to the documentation, the ctid value is not recommended to be used since it can change after a VACCUM. But, which value could I store? Any recommendation?
How to directly access the set of tuples that are pointed by the returned rowids of task 2? One solution would be to use SQL query. However, is it efficient? I mean, I am writing a extension of PostgreSQL, therefore, I have access to its internal library. Is there a direct way to do it instead of use sql queries? Is it a good and efficient solution use SQL queries with SPI?
These are two different questions and you shouldn't ask compound questions on StackExchange.


What tuple identifier would be the best to be stored in the task 1? According to the documentation, the ctid value is not recommended to be used since it can change after a VACCUM. But, which value could I store? Any recommendation?

Create your own ID. PostgreSQL doesn't create you IDs for userspace unless you explicitly request it: which you can do with GENERATED BY DEFAULT AS IDENTITY (or serial in pre-PostgreSQL 10)
How to directly access the set of tuples that are pointed by the returned rowids of task 2? One solution would be to use SQL query. However, is it efficient? I mean, I am writing a extension of PostgreSQL, therefore, I have access to its internal library. Is there a direct way to do it instead of use sql queries? Is it a good and efficient solution use SQL queries with SPI?

You don't. PostgreSQL isn't intentionally slow if there was a faster and safer way to do something by default, it would be done. Without knowing what compromises you're willing to make that the server isn't, there is no way to answer this question.

If you're not willing to make additionally compromises, it's not likely you could safe more time without a total rewrite, or merely preplanning the UPDATE.

An extension doesn't magically make everything faster.