Re: Multi Inserts in CREATE TABLE AS - revived patch - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Multi Inserts in CREATE TABLE AS - revived patch
Date
Msg-id CAFiTN-voX_opJ_qYTb3G8=ccXbUQdUoYoxs89XjMAiuuXLCEjQ@mail.gmail.com
Whole thread Raw
In response to Re: Multi Inserts in CREATE TABLE AS - revived patch  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Multi Inserts in CREATE TABLE AS - revived patch
List pgsql-hackers
On Mon, Nov 30, 2020 at 10:49 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> Currently, required logic for multi inserts (such as buffer slots allocation, flushing, tuple size calculation to
decidewhen to flush, cleanup and so on) is being handled outside of the existing tableam APIs. And there are a good
numberof cases where multi inserts can be used, such as for existing COPY or for CTAS, CREATE/REFRESH MATERIALIZED VIEW
[proposedin this thread], and INSERT INTO SELECTs [here] which are currently under discussion. Handling the same multi
insertslogic in many places is error prone and duplicates most of the code. To avoid this, proposing here are generic
tableamAPIs, that can be used in all the cases and which also gives the flexibility to tableam developers in
implementingmulti inserts logic dependent on the underlying storage engine[1]. 
>
> I would like to seek thoughts/opinions on the proposed new APIs. Once reviewed, I will start implementing them.

IMHO, if we think that something really specific to the tableam then
it makes sense to move it there.  But just to avoid duplicating the
code it might not be the best idea.  Instead, you can write some
common functions and we can call them from different places.  So if
something is very much common and will not vary based on the storage
type we can keep it outside the tableam interface however we can move
them into some common functions to avoid duplication.


--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: SELECT INTO deprecation
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Huge memory consumption on partitioned table with FKs