Re: Fast COPY FROM based on batch insert
От | Andrey Lepikhov |
---|---|
Тема | Re: Fast COPY FROM based on batch insert |
Дата | |
Msg-id | ed89807e-0c15-02ac-b0aa-c01cdc5a2b2e@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Fast COPY FROM based on batch insert (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: Fast COPY FROM based on batch insert
|
Список | pgsql-hackers |
On 7/22/22 13:14, Etsuro Fujita wrote: > On Fri, Jul 22, 2022 at 3:39 PM Andrey Lepikhov > <a.lepikhov@postgrespro.ru> wrote: >> Analyzing multi-level heterogeneous partitioned configurations I >> realized, that single write into a partition with a trigger will flush >> buffers for all other partitions of the parent table even if the parent >> haven't any triggers. >> It relates to the code: >> else if (insertMethod == CIM_MULTI_CONDITIONAL && >> !CopyMultiInsertInfoIsEmpty(&multiInsertInfo)) >> { >> /* >> * Flush pending inserts if this partition can't use >> * batching, so rows are visible to triggers etc. >> */ >> CopyMultiInsertInfoFlush(&multiInsertInfo, resultRelInfo); >> } >> >> Why such cascade flush is really necessary, especially for BEFORE and >> INSTEAD OF triggers? > > BEFORE triggers on the chosen partition might query the parent table, > not just the partition, so I think we need to do this so that such > triggers can see all the rows that have been inserted into the parent > table until then. if you'll excuse me, I will add one more argument. It wasn't clear, so I've made an experiment: result of a SELECT in an INSERT trigger function shows only data, existed in the parent table before the start of COPY. So, we haven't tools to access newly inserting rows in neighboring partition and don't need to flush tuple buffers immediately. Where am I wrong? -- Regards Andrey Lepikhov Postgres Professional
В списке pgsql-hackers по дате отправления: