Re: Extracting only the columns needed for a query

From: Ashwin Agrawal <aagrawal(at)pivotal(dot)io>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, 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-31 18:05:23
Message-ID: CALfoeivsmiuC7eJEjyNVBrZV+kG2YP08j_3qU_KWJxvV0RSZ9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 15, 2020 at 7:54 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:

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

The table_tuple_lock() has TupleTableSlot as output argument. Comment for
the function states "*slot: contains the target tuple". Usage of
table_tuple_lock() in places like ExecUpdate() and GetTupleForTrigger() use
the returned tuple for EvalPlanQual. Also, it's unknown
within table_tuple_lock() what is expectation and what would be
performed on the returned slot/tuple. Hence, it becomes tricky for any AM
currently to guess and hence need to return full tuple, as API doesn't
state only which columns it would be interested in or just wishes to take
the lock and needs nothing back in slot.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-01-31 18:37:40 Re: Shared memory leak on DSM slot exhaustion
Previous Message Melanie Plageman 2020-01-31 17:52:09 Re: Extracting only the columns needed for a query