> On Thu, Jan 02, 2020 at 05:21:55PM -0800, Melanie Plageman wrote: > > That makes me think that maybe the function name, > extract_used_columns() is bad, though. Maybe extract_scan_columns()? > I tried this in the attached, updated patch.
Thanks, I'll take a look at the new version. Following your explanation extract_scan_columns sounds better, but at the same time scan is pretty broad term and one can probably misunderstand what kind of scan is that in the name. > For UPDATE, we need all of the columns in the table because of the > table_lock() API's current expectation that the slot has all of the > columns populated. If we want UPDATE to only need to insert the column > values which have changed, table_tuple_lock() will have to change. Can you please elaborate on this part? I'm probably missing something, since I don't see immediately where are those expectations expressed. > > AM callback relation_estimate_size exists currently which planner leverages. > > Via this callback it fetches tuples, pages, etc.. So, our thought is to > > extend > > this API if possible to pass down needed column and help perform better > > costing > > for the query. Though we think if wish to leverage this function, need to > > know > > list of columns before planning hence might need to use query tree. > > I believe it would be beneficial to add this potential API extension patch > into > the thread (as an example of an interface defining how scanCols could be used) > and review them together. I still find this question from my previous email interesting to explore.
