From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Luc Vlaming <luc(at)swarm64(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Paul Guo <guopa(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Multi Inserts in CREATE TABLE AS - revived patch |
Date: | 2020-12-03 08:08:15 |
Message-ID: | CAFiTN-voX_opJ_qYTb3G8=ccXbUQdUoYoxs89XjMAiuuXLCEjQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 30, 2020 at 10:49 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> Currently, required logic for multi inserts (such as buffer slots allocation, flushing, tuple size calculation to decide when to flush, cleanup and so on) is being handled outside of the existing tableam APIs. And there are a good number of cases where multi inserts can be used, such as for existing COPY or for CTAS, CREATE/REFRESH MATERIALIZED VIEW [proposed in this thread], and INSERT INTO SELECTs [here] which are currently under discussion. Handling the same multi inserts logic in many places is error prone and duplicates most of the code. To avoid this, proposing here are generic tableam APIs, that can be used in all the cases and which also gives the flexibility to tableam developers in implementing multi 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-12-03 08:13:16 | Re: Huge memory consumption on partitioned table with FKs |
Previous Message | Thomas Kellerer | 2020-12-03 08:01:39 | Re: SELECT INTO deprecation |