From: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UPDATE of partition key |
Date: | 2017-02-16 06:50:54 |
Message-ID: | CAJ3gD9fFJ_TnqOfuYLddjiGFOoUDmO05A2PCSR7XXe6pfSwzjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15 February 2017 at 20:26, David Fetter <david(at)fetter(dot)org> wrote:
> When an UPDATE can't happen, there are often ways to hint at
> what went wrong and how to correct it. Violating a uniqueness
> constraint would be one example.
>
> When an UPDATE can't happen and the depth of the subtree is a
> plausible candidate for what prevents it, there might be a way to say
> so.
>
> Let's imagine a table called log with partitions on "stamp" log_YYYY
> and subpartitions, also on "stamp", log_YYYYMM. If you do something
> like
>
> UPDATE log_2017 SET "stamp"='2016-11-08 23:03:00' WHERE ...
>
> it's possible to know that it might have worked had the UPDATE taken
> place on log rather than on log_2017.
>
> Does that make sense, and if so, is it super invasive to HINT that?
Yeah, I think it should be possible to find the root partition with
the help of pg_partitioned_table, and then run ExecFindPartition()
again using the root. Will check. I am not sure right now how involved
that would turn out to be, but I think that logic would not change the
existing code, so in that sense it is not invasive.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-02-16 07:13:01 | Re: Documentation improvements for partitioning |
Previous Message | Peter Geoghegan | 2017-02-16 06:35:34 | Re: ICU integration |