Re: Multi Inserts in CREATE TABLE AS - revived patch
От | Dilip Kumar |
---|---|
Тема | Re: Multi Inserts in CREATE TABLE AS - revived patch |
Дата | |
Msg-id | CAFiTN-voX_opJ_qYTb3G8=ccXbUQdUoYoxs89XjMAiuuXLCEjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Multi Inserts in CREATE TABLE AS - revived patch (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Multi Inserts in CREATE TABLE AS - revived patch
|
Список | 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 по дате отправления: