On Sun, Aug 5, 2018 at 3:49 PM, Andres Freund <and...@anarazel.de> wrote: > Hi, > > Working on rebasing the pluggable storage patch on the current version > of this.
Thanks. Please let me know if you see any issues. > > On 2018-07-26 17:09:08 +0530, Ashutosh Bapat wrote: >> Done. I also noticed that slot_getattr() optimizes the cases when the >> requested attributes is NULL or is missing from a tuple. Given that a >> custom TupleTableSlot type can have its own optimizations for the >> same, added a new call back getattr() to obtain value of a given >> attribute from slot. The callback is called from slot_getattr(). > > I'm quite against this. This is just proliferation of callbacks without > much use. Why do you think this is helpful? I think it's much better > to go back to a single callback to deform here. > I think, I explained why getattr() needs to be a separate callback. There's a reason why slot_getattr() more code than just calling slot_getsomeattrs() and return the required one - the cases when the requested attribute is NULL or is missing from a tuple. Depending upon the tuple layout access to a simple attribute can be optimized without spending cycles to extract attributes prior to that one. Columnar store (I haven't seen Haribabu's patch), for example, stores columns from multiple rows together and thus doesn't have a compact version of tuple. In such cases extracting an individual attribute directly is far cheaper than extracting all the previous attributes. Why should we force the storage API to extract all the attributes in such a case? -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company