Melanie Plageman <melanieplageman@gmail.com> writes:
> While hacking on zedstore, we needed to get a list of the columns to
> be projected--basically all of the columns needed to satisfy the
> query. The two use cases we have for this is
> 1) to pass this column list down to the AM layer for the AM to leverage it
> 2) for use during planning to improving costing
> In other threads, such as [1], there has been discussion about the
> possible benefits for all table types of having access to this set of
> columns.
The thing that most approaches to this have fallen down on is triggers ---
that is, a trigger function might access columns mentioned nowhere in the
SQL text. (See 8b6da83d1 for a recent example :-() If you have a plan
for dealing with that, then ...
For triggers, there's not much we can do since we don't know what
columns the trigger function requires. All of the columns will have to
be scanned for GetTupleForTrigger().
The initial scan can still use the scanCols, though.
Currently, when we use the scanCols, triggers work because
GetTupleForTrigger() will call table_tuple_lock(). tuple_table_lock()
expects the return slot to be populated with the latest fetched
tuple--which will have all of the columns.
So, you don't get any kind of optimization, but, really, with the
current TRIGGER/FUNCTION syntax, it doesn't seem like we could do
better than that.
Ashwin & Melanie
