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