On Sat, 15 Jun 2019 at 13:46, Melanie Plageman <melanieplage...@gmail.com> wrote: > > While hacking on zedstore, we needed to get a list of the columns to > be projected--basically all of the columns needed to satisfy the > query. The two use cases we have for this is > 1) to pass this column list down to the AM layer for the AM to leverage it > 2) for use during planning to improving costing > In other threads, such as [1], there has been discussion about the > possible benefits for all table types of having access to this set of > columns. > > Focusing on how to get this used cols list (as opposed to how to pass > it down to the AM), we have tried a few approaches to constructing it > and wanted to get some ideas on how best to do it. > > We are trying to determine which phase to get the columns -- after > parsing, after planning, or during execution right before calling the > AM.
For planning, isn't this information already available via either targetlists or from the RelOptInfo->attr_needed array combined with min_attr and max_attr? If it's going to be too much overhead to extract vars from the targetlist during executor startup then maybe something can be done during planning to set a new Bitmapset field of attrs in RangeTblEntry. Likely that can be built easily by looking at attr_needed in RelOptInfo. Parse is too early to set this as which attributes are needed can change during planning. For example, look at remove_rel_from_query() in analyzejoins.c. If you don't need access to this during planning then maybe setrefs.c is a good place to set something. Although, it would be nice not to add this overhead when the executor does not need this information. I'm unsure how the planner could know that though, other than by having another tableam callback function to tell it. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
