Re: Batch insert in CTAS/MatView code

From: Paul Guo <pguo(at)pivotal(dot)io>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Asim R P <apraveen(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 04:22:50
Message-ID: CAEET0ZFaHw2zPHOM2EABV07e0ngkLxQBj6VwBQ70PBvgYH2B=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 26, 2019 at 9:43 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?)
>
> Also:
>
> + myState->mi_slots_size >= 65535)
>
> This magic number should be placed in a define next to the other one,
> but I'm not sure that heapam.h is a good location, since surely this
> applies to matviews in other table AMs too.
>
> yes defining 65535 seems better. Let's fix this one later when having
more feedback. Thanks.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-09-27 04:51:25 Re: pg_wal/RECOVERYHISTORY file remains after archive recovery
Previous Message Paul Guo 2019-09-27 04:18:31 Re: Batch insert in CTAS/MatView code