Re: Extracting only the columns needed for a query

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
Date: 2020-01-15 15:54:27
Message-ID: 20200115155427.ppuhgl7vzhk77iyt@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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.

In response to


Browse pgsql-hackers by date

  From Date Subject
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