From: | Asim R P <apraveen(at)pivotal(dot)io> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Paul Guo <pguo(at)pivotal(dot)io>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Taylor Vesely <tvesely(at)pivotal(dot)io>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Batch insert in CTAS/MatView code |
Date: | 2019-09-27 07:03:47 |
Message-ID: | CANXE4Tcmg544+D71cRT7cJq-MkXob8zYfSPOe4rripc_7Aqmmw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 26, 2019 at 7:13 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-09-27 07:14:01 | Re: Refactoring of connection with password prompt loop for frontends |
Previous Message | Masahiko Sawada | 2019-09-27 07:02:00 | Re: recovery starting when backup_label exists, but not recovery.signal |