Re: Tid scan improvements

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Tid scan improvements
Дата
Msg-id CAApHDvqDcx3_CM1Y4hiCv7q3o3iLFsF1g=SQ5B=6NJoSPEDA_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tid scan improvements  (Andres Freund <andres@anarazel.de>)
Ответы Re: Tid scan improvements  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Thanks for looking at this.

On Thu, 4 Feb 2021 at 10:19, Andres Freund <andres@anarazel.de> wrote:
> Perhaps something like
>
> typedef struct TableScanTidRange TableScanTidRange;
>
> TableScanTidRange* table_scan_tid_range_start(TableScanDesc sscan, ItemPointer mintid, ItemPointer maxtid);
> bool table_scan_tid_range_nextslot(TableScanDesc sscan, TableScanTidRange *range, TupleTableSlot *slot);
> void table_scan_tid_range_end(TableScanDesc sscan, TableScanTidRange* range);
>
> would work better? That'd allow an AM to have arbitrarily large state
> for a tid range scan, would make it clear what the lifetime of the
> ItemPointer mintid, ItemPointer maxtid are etc.  Wouldn't, on the API
> level, prevent multiple tid range scans from being in progress at the
> same times though :(. Perhaps we could add a TableScanTidRange* pointer
> to TableScanDesc which'd be checked/set by tableam.h which'd prevent that?

Maybe the TableScanTidRange can just have a field to store the
TableScanDesc. That way table_scan_tid_range_nextslot and
table_scan_tid_range_end can just pass the TableScanTidRange pointer.

That way it seems like it would be ok for multiple scans to be going
on concurrently as nobody should be reusing the TableScanDesc.

Does that seem ok?

David



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Tid scan improvements
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Can we have a new SQL callable function to get Postmaster PID?