On 2018/09/28 11:46, David Rowley wrote:
> On 28 September 2018 at 14:25, Amit Langote
> <Langote_Amit_f8@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