Hi, FWIW, now that oids are removed, and the tuple table slot abstraction got in, I'm working on rebasing the pluggable storage patchset ontop of that.
On 2018-11-27 12:48:36 +1100, Haribabu Kommi wrote: > On Thu, Nov 22, 2018 at 1:12 PM Asim R P <aprav...@pivotal.io> wrote: > > > Ashwin (copied) and I got a chance to go through the latest code from > > Andres' github repository. We would like to share some > > comments/quesitons: > > > > Thanks for the review. > > > > The TupleTableSlot argument is well suited for row-oriented storage. > > For a column-oriented storage engine, a projection list indicating the > > columns to be scanned may be necessary. Is it possible to share this > > information with current interface? > > > > Currently all the interfaces are designed for row-oriented storage, as you > said we need a new API for projection list. The current patch set itself > is big and it needs to stabilized and then in the next set of the patches, > those new API's will be added that will be useful for columnar storage. Precisely. > > TupleDelete_function() accepts changingPart as a parameter to indicate > > if this deletion is part of a movement from one partition to another. > > Partitioning is a higher level abstraction as compared to storage. > > Ideally, storage layer should have no knowledge of partitioning. The > > tuple delete API should not accept any parameter related to > > partitioning. > > > > Thanks for your point, will look into it in how to change extract it. I don't think that's actually a problem. The changingPart parameter is just a marker that the deletion is part of moving a tuple across partitions. For heap and everythign compatible that's used to include information to the tuple that concurrent modifications to the tuple should error out when reaching such a tuple via EPQ. > Andres, as the tupletableslot changes are committed, do you want me to > share the rebased pluggable storage patch? you already working on it? Working on it. Greetings, Andres Freund
