On Sat, 15 Jun 2019 at 13:46, Melanie Plageman
<melanieplageman@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