Re: Declarative partitioning - another take
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
Attachments
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
Commits
-
Fix typo.
- 03bf59676ea0 10.0 landed
-
Document trigger-firing behavior for inheritance/partitioning.
- e17628145ac3 10.0 landed
-
Fire per-statement triggers on partitioned tables.
- e180c8aa8caf 10.0 landed
-
Set ecxt_scantuple correctly for tuple routing.
- 132488bfee68 10.0 landed
-
Fix interaction of partitioned tables with BulkInsertState.
- b1ecb9b3fcfb 10.0 landed
-
Avoid core dump for empty prepared statement in an aborted transaction.
- ba61a04bc7fe 10.0 cited
-
Fix some problems in check_new_partition_bound().
- 8a8afe2f54c2 10.0 landed
-
Remove unnecessary arguments from partitioning functions.
- 18fc5192a631 10.0 cited
-
Fix reporting of constraint violations for table partitioning.
- f1b4c771ea74 10.0 cited
-
Fix tuple routing in cases where tuple descriptors don't match.
- 2ac3ef7a01df 10.0 cited
-
Invalid parent's relcache after CREATE TABLE .. PARTITION OF.
- 7cd0fd655d68 10.0 landed
-
Doc: improve documentation about inheritance.
- 162477a63d3c 10.0 cited