On Sat, Jun 15, 2019 at 10:01 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Melanie Plageman <melanieplage...@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
