On Thu, Sep 26, 2019 at 7:13 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > On 2019-Sep-25, Asim R P wrote: > > > I reviewed your patch today. It looks good overall. My concern is that > > the ExecFetchSlotHeapTuple call does not seem appropriate. In a generic > > place such as createas.c, we should be using generic tableam API only. > > However, I can also see that there is no better alternative. We need to > > compute the size of accumulated tuples so far, in order to decide whether > > to stop accumulating tuples. There is no convenient way to obtain the > > length of the tuple, given a slot. How about making that decision solely > > based on number of tuples, so that we can avoid ExecFetchSlotHeapTuple call > > altogether? > > ... maybe we should add a new operation to slots, that returns the > (approximate?) size of a tuple? That would make this easy. (I'm not > sure however what to do about TOAST considerations -- is it size in > memory that we're worried about?)
That will help. For slots containing heap tuples, heap_compute_data_size() is what we need. Approximate size is better than nothing. In case of CTAS, we are dealing with slots returned by a scan node. Wouldn't TOAST datums be already expanded in those slots? Asim