Re: Tid scan improvements
От | David Rowley |
---|---|
Тема | Re: Tid scan improvements |
Дата | |
Msg-id | CAKJS1f9DBpoZk5Fhyq5eQu3YfAWo8E7J2zEPSz70J=im8rVngw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tid scan improvements (Edmund Horner <ejrh00@gmail.com>) |
Ответы |
Re: Re: Tid scan improvements
Re: Tid scan improvements |
Список | pgsql-hackers |
On Fri, 15 Mar 2019 at 18:42, Edmund Horner <ejrh00@gmail.com> wrote: > I've had to adapt it to use the table scan API. I've got it compiling > and passing tests, but I'm uneasy about some things that still use the > heapam API. > > 1. I call heap_setscanlimits as I'm not sure there is a tableam equivalent. > 2. I'm not sure whether non-heap tableam implementations can also be > supported by my TID Range Scan: we need to be able to set the scan > limits. There may not be any other implementations yet, but when > there are, how do we stop the planner using a TID Range Scan for > non-heap relations? > 3. When fetching tuples, I see that nodeSeqscan.c uses > table_scan_getnextslot, which saves dealing with HeapTuples. But > nodeTidrangescan wants to do some checking of the block and offset > before returning the slot. So I have it using heap_getnext and > ExecStoreBufferHeapTuple. Apart from being heapam-specific, it's just > not as clean as the new API calls. > > Ideally, we can get to to support general tableam implementations > rather than using heapam-specific calls. Any advice on how to do > this? The commit message in 8586bf7ed mentions: > Subsequent commits will incrementally abstract table access > functionality to be routed through table access methods. That change > is too large to be reviewed & committed at once, so it'll be done > incrementally. and looking at [1] I see patch 0004 introduces some changes in nodeTidscan.c to call a new tableam API function named heapam_fetch_row_version. I see this function does have a ItemPointer argument, so I guess we must be keeping those as unique row identifiers in the API. Patch 0001 does change the signature of heap_setscanlimits() (appears to be committed already), and then in 0010 the only code that calls heap_setscanlimits() (IndexBuildHeapRangeScan()) is moved and renamed to heapam_index_build_range_scan() and set to be called via the index_build_range_scan TableAmRoutine method. So it looks like out of that patch series nothing is there to allow you to access heap_setscanlimits() directly via the TableAmRoutine API, so perhaps for this to work heap_setscanlimits will need to be interfaced, however, I'm unsure if that'll violate any assumptions that Andres wants to keep out of the API... Andres? [1] https://www.postgresql.org/message-id/20190311193746.hhv4e4e62nxtq3k6@alap3.anarazel.de -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Arseny SherДата:
Сообщение: Re: Parallel query vs smart shutdown and Postmaster death