|From:||Dmitry Dolgov <9erthalion6(at)gmail(dot)com>|
|To:||Melanie Plageman <melanieplageman(at)gmail(dot)com>|
|Cc:||Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>|
|Subject:||Re: Extracting only the columns needed for a query|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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.
|Next Message||Sergei Kornilov||2020-01-15 16:15:44||Re: Rearranging ALTER TABLE to avoid multi-operations bugs|
|Previous Message||Peter Eisentraut||2020-01-15 15:25:37||Re: our checks for read-only queries are not great|