Re: [HACKERS] Declarative partitioning - another take
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Declarative partitioning - another take |
Дата | |
Msg-id | 01bc4745-bac8-a033-96a1-8a42b45d2fc1@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Declarative partitioning - another take (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Declarative partitioning - another take
Re: [HACKERS] Declarative partitioning - another take |
Список | pgsql-hackers |
On 2017/01/05 3:26, Robert Haas wrote: > On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote > <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> On 2016/12/27 19:07, Amit Langote wrote: >>> Attached should fix that. >> >> Here are the last two patches with additional information like other >> patches. Forgot to do that yesterday. > > 0001 has the disadvantage that get_partition_for_tuple() acquires a > side effect. That seems undesirable. At the least, it needs to be > documented in the function's header comment. That's true. How about we save away the original ecxt_scantuple at entry and restore the same just before returning from the function? That way there would be no side effect. 0001 implements that. > It's unclear to me why we need to do 0002. It doesn't seem like it > should be necessary, it doesn't seem like a good idea, and the commit > message you proposed is uninformative. If a single BulkInsertState object is passed to heap_insert()/heap_multi_insert() for different heaps corresponding to different partitions (from one input tuple to next), tuples might end up going into wrong heaps (like demonstrated in one of the reports [1]). A simple solution is to disable bulk-insert in case of partitioned tables. But my patch (or its motivations) was slightly wrongheaded, wherein I conflated multi-insert stuff and bulk-insert considerations. I revised 0002 to not do that. However if we disable bulk-insert mode, COPY's purported performance benefit compared with INSERT is naught. Patch 0003 is a proposal to implement bulk-insert mode even for partitioned tables. Basically, allocate separate BulkInsertState objects for each partition and switch to the appropriate one just before calling heap_insert()/heap_multi_insert(). Then to be able to use heap_multi_insert(), we must also manage buffered tuples separately for each partition. Although, I didn't modify the limit on number of buffered tuples and/or size of buffered tuples which controls when we pause buffering and do heap_multi_insert() on buffered tuples. Maybe, it should work slightly differently for the partitioned table case, like for example, increase the overall limit on both the number of tuples and tuple size in the partitioning case (I observed that increasing it 10x or 100x helped to some degree). Thoughts on this? Thanks, Amit [1] https://www.postgresql.org/message-id/CAFmBtr32FDOqofo8yG-4mjzL1HnYHxXK5S9OGFJ%3D%3DcJpgEW4vA%40mail.gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: