From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal) |
Date: | 2018-09-28 03:54:10 |
Message-ID: | 92aa1059-d5de-bc50-ccb5-e2e8391317a1@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/09/28 11:46, David Rowley wrote:
> On 28 September 2018 at 14:25, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-09-28 04:02:56 | Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal) |
Previous Message | Andres Freund | 2018-09-28 03:40:26 | Re: Use durable_unlink for .ready and .done files for WAL segment removal |