On 2018/09/28 11:46, David Rowley wrote: > On 28 September 2018 at 14:25, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Looking at the patch itself, does it seem like both the newly added >> comments repeat the same point (that we'll need per-partition hi_options >> to enable these optimizations) and are pretty close to each other? > > Thanks for looking at this. > > I don't agree that we can skip explaining why one of the optimisations > can't be applied just because we've explained why a similar > optimisation cannot be applied somewhere close by. I think that the > WAL/FSM optimisation can fairly easily be improved on and probably > fixed in PG12 as we can just lazily determine per-partition if it can > be applied to that partition or not. > > For the FREEZE optimisation, since we ERROR out in cases where it's > requested but is not possible, it does not seem likely we'll ever fix > that since to do that we'd need to determine that all partitions have > just been truncated or were only just created in this transaction. > Since we've both recently done a bit of work in the area of speeding > up COPY, then I doubt either of us would like to go and slow it down > again by adding a pre-check that goes and opens all the partitions > before the copy begins. That's going to have a huge negative > performance impact on small copies to 1 partition when there are many > partitions attached. > > So in this regard, you'll notice that the comments are not that > similar. One explains that we could improve on it, and the other > attempts to mention that it would be surprising if we performed a > FREEZE for some partitions but not others.
Okay, I see the difference. I didn't really intend to ask to remove the second comment altogether; just the part which repeats the why (that actual relations that the data will go into are not handy for inspection at this point). Looking at the second comment: +/* + * We currently disallow COPY FREEZE on partitioned tables. The + * reason for this is that here we're only able to determine details + * about the partitioned table. The actual partitions are not opened + * until we start routing tuples to them, so we cannot know in advance + * if the partition has just been created or not. It may be possible + * to relax this, but we would need to store hi_options per partition + * and it would possibly mean that we'd freeze some partitions but not + * others. An outright ERROR seems better than surprising behavior. + */ Does this comment mean that we *may* consider removing this ERROR in the future and continue with the optimization on per-partition basis even if, as it says, it might mean that some partitions will contain frozen rows while others not? Thanks, Amit
