On Thu, Jun 1, 2017 at 3:25 AM, Robert Haas wrote:
> On Mon, May 29, 2017 at 5:26 AM, Amit Kapila wrote:
>>> But I think, we can also take step-by-step approach even for v11. If
>>> we agree that it is ok to silently do the updates as long as we
>>> document the behaviour, we can go ahead and do
On Fri, Jun 2, 2017 at 4:37 PM, Amit Khandekar wrote:
> On 2 June 2017 at 01:17, Robert Haas wrote:
>> On Thu, Jun 1, 2017 at 7:41 AM, Amit Khandekar
>> wrote:
Regarding the trigger issue, I can't claim to have a terribly strong
opinion on this. I think that practically anything we d
On 2 June 2017 at 01:17, Robert Haas wrote:
> On Thu, Jun 1, 2017 at 7:41 AM, Amit Khandekar wrote:
>>> Regarding the trigger issue, I can't claim to have a terribly strong
>>> opinion on this. I think that practically anything we do here might
>>> upset somebody, but probably any halfway-reason
On Thu, Jun 1, 2017 at 7:41 AM, Amit Khandekar wrote:
>> Regarding the trigger issue, I can't claim to have a terribly strong
>> opinion on this. I think that practically anything we do here might
>> upset somebody, but probably any halfway-reasonable thing we choose to
>> do will be OK for most
On 1 June 2017 at 03:25, Robert Haas wrote:
> Greg/Amit's idea of using the CTID field rather than an infomask bit
> seems like a possibly promising approach. Not everything that needs
> bit-space can use the CTID field, so using it is a little less likely
> to conflict with something else we wan
On Mon, May 29, 2017 at 5:26 AM, Amit Kapila wrote:
>> But I think, we can also take step-by-step approach even for v11. If
>> we agree that it is ok to silently do the updates as long as we
>> document the behaviour, we can go ahead and do this, and then as a
>> second step, implement error handl
On Mon, May 29, 2017 at 11:20 AM, Amit Khandekar wrote:
> On 24 May 2017 at 20:16, Amit Kapila wrote:
>> On Wed, May 24, 2017 at 8:14 PM, Amit Kapila wrote:
>>> Apart from above, there is one open issue [1]
>>>
>>
>> Forget to mention the link, doing it now.
>>
>> [1] -
>> https://www.postgresq
On 24 May 2017 at 20:16, Amit Kapila wrote:
> On Wed, May 24, 2017 at 8:14 PM, Amit Kapila wrote:
>> Apart from above, there is one open issue [1]
>>
>
> Forget to mention the link, doing it now.
>
> [1] -
> https://www.postgresql.org/message-id/CAA4eK1KEZQ%2BCyXbBzfn1jFHoEfa_OemDLhLyy7xfD1QUZLo
On Wed, May 24, 2017 at 8:14 PM, Amit Kapila wrote:
> On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar
> wrote:
>>
>> By now, majority of the opinions have shown that they do not favour
>> two triggers getting fired on a single update. Amit, do you consider
>> option 2 as a valid option ?
>>
>
>
On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar wrote:
> On 18 May 2017 at 16:52, Amit Kapila wrote:
>> On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar wrote:
>>> On Wed, May 17, 2017 at 3:15 PM, Amit Kapila
>>> wrote:
> Earlier I thought that option1 is better but later I think that this
>>>
On 12 May 2017 at 09:27, Amit Kapila wrote:
>
> + is_partitioned_table =
> + root_rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE;
> +
> + if (is_partitioned_table)
> + ExecSetupPartitionTupleRouting(
> + root_rel,
> + /* Build WITH CHECK OPTION constraints for leaf partitions */
> + ExecInitPar
On 18 May 2017 at 16:52, Amit Kapila wrote:
> On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar wrote:
>> On Wed, May 17, 2017 at 3:15 PM, Amit Kapila wrote:
Earlier I thought that option1 is better but later I think that this
can complicate the situation as we are firing first BR update th
On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar wrote:
> On Wed, May 17, 2017 at 3:15 PM, Amit Kapila wrote:
>>> Earlier I thought that option1 is better but later I think that this
>>> can complicate the situation as we are firing first BR update then BR
>>> delete and can change the row multiple t
On 17 May 2017 at 17:29, Rushabh Lathia wrote:
>
>
> On Wed, May 17, 2017 at 12:06 PM, Dilip Kumar wrote:
>>
>> On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar
>> wrote:
>> > Option 3
>> >
>> >
>> > BR, AR delete triggers on source partition
>> > BR, AR insert triggers on destination pa
On Wed, May 17, 2017 at 5:17 PM, Robert Haas wrote:
> On Wed, May 17, 2017 at 6:29 AM, Amit Kapila wrote:
>> I think we can do this even without using an additional infomask bit.
>> As suggested by Greg up thread, we can set InvalidBlockId in ctid to
>> indicate such an update.
>
> Hmm. How wou
On Wed, May 17, 2017 at 12:06 PM, Dilip Kumar wrote:
> On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar
> wrote:
> > Option 3
> >
> >
> > BR, AR delete triggers on source partition
> > BR, AR insert triggers on destination partition.
> >
> > Rationale :
> > Since the update is converted
On Wed, May 17, 2017 at 6:29 AM, Amit Kapila wrote:
> I think we can do this even without using an additional infomask bit.
> As suggested by Greg up thread, we can set InvalidBlockId in ctid to
> indicate such an update.
Hmm. How would that work?
--
Robert Haas
EnterpriseDB: http://www.enterp
On Wed, May 17, 2017 at 3:15 PM, Amit Kapila wrote:
>> Earlier I thought that option1 is better but later I think that this
>> can complicate the situation as we are firing first BR update then BR
>> delete and can change the row multiple time and defining such
>> behaviour can be complicated.
>>
On Mon, May 15, 2017 at 5:28 PM, Robert Haas wrote:
> On Fri, May 12, 2017 at 3:07 AM, Amit Kapila wrote:
>> I agree with you that it might not be straightforward to make it work,
>> but now that earliest it can go is v11, do we want to try doing
>> something other than just documenting it. What
On Wed, May 17, 2017 at 12:06 PM, Dilip Kumar wrote:
> On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar
> wrote:
>> Option 3
>>
>>
>> BR, AR delete triggers on source partition
>> BR, AR insert triggers on destination partition.
>>
>> Rationale :
>> Since the update is converted to delet
On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar wrote:
> Option 3
>
>
> BR, AR delete triggers on source partition
> BR, AR insert triggers on destination partition.
>
> Rationale :
> Since the update is converted to delete+insert, just skip the update
> triggers completely.
+1 to option
On Fri, May 12, 2017 at 3:07 AM, Amit Kapila wrote:
> I agree with you that it might not be straightforward to make it work,
> but now that earliest it can go is v11, do we want to try doing
> something other than just documenting it. What I could read from this
> e-mail thread is that you are in
On 12 May 2017 at 14:56, Amit Kapila wrote:
> I think it might be better to summarize all the options discussed
> including what the patch has and see what most people consider as
> sensible.
Yes, makes sense. Here are the options that were discussed so far for
ROW triggers :
Option 1 : (the pat
On Fri, May 12, 2017 at 10:49 AM, Amit Khandekar wrote:
> On 12 May 2017 at 08:30, Amit Kapila wrote:
>> On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar
>> wrote:
>
>> If we try to compare it with the non-partitioned update,
>> there also it is internally a delete and insert operation, but we
>
On Fri, Feb 24, 2017 at 3:50 PM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 3:24 PM, Simon Riggs wrote:
>
>> It is of course very good that we have something ready for this
>> release and can make a choice of what to do.
>>
>> Thoughts
>>
>> 1. Reuse the tuple state HEAP_MOVED_OFF which IIRC re
>> 3.
>> + longer satisfy the partition constraint of the containing partition. In
>> that
>> + case, if there is some other partition in the partition tree for which
>> this
>> + row satisfies its partition constraint, then the row is moved to that
>> + partition. If there isn't such a p
On 12 May 2017 at 08:30, Amit Kapila wrote:
> On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar
> wrote:
>> On 11 May 2017 at 17:23, Amit Kapila wrote:
>>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
>>> wrote:
On 4 March 2017 at 12:49, Robert Haas wrote:
> On Thu, Mar 2, 2017 at
On 12 May 2017 at 10:01, Amit Kapila wrote:
> On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote:
>> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar
>> wrote:
>>> On 11 May 2017 at 17:24, Amit Kapila wrote:
Few comments:
1.
Operating directly on partition doesn't allow update to
On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote:
> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar
> wrote:
>> On 11 May 2017 at 17:24, Amit Kapila wrote:
>>> Few comments:
>>> 1.
>>> Operating directly on partition doesn't allow update to move row.
>>> Refer below example:
>>> create table
On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:24, Amit Kapila wrote:
>> Few comments:
>> 1.
>> Operating directly on partition doesn't allow update to move row.
>> Refer below example:
>> create table t1(c1 int) partition by range(c1);
>> create table t1_part_1 par
On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:23, Amit Kapila wrote:
>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
>> wrote:
>>> On 4 March 2017 at 12:49, Robert Haas wrote:
On Thu, Mar 2, 2017 at 11:53 AM, Amit Khandekar
wrote:
> I think it
On 11 May 2017 at 17:24, Amit Kapila wrote:
> Few comments:
> 1.
> Operating directly on partition doesn't allow update to move row.
> Refer below example:
> create table t1(c1 int) partition by range(c1);
> create table t1_part_1 partition of t1 for values from (1) to (100);
> create table t1_par
On 11 May 2017 at 17:23, Amit Kapila wrote:
> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
> wrote:
>> On 4 March 2017 at 12:49, Robert Haas wrote:
>>> On Thu, Mar 2, 2017 at 11:53 AM, Amit Khandekar
>>> wrote:
I think it does not make sense running after row triggers in case of
On Thu, May 11, 2017 at 7:54 AM, Amit Kapila wrote:
> Few comments:
> 1.
> Operating directly on partition doesn't allow update to move row.
> Refer below example:
> create table t1(c1 int) partition by range(c1);
> create table t1_part_1 partition of t1 for values from (1) to (100);
> create tabl
On Wed, May 3, 2017 at 11:22 AM, Amit Khandekar wrote:
> On 2 May 2017 at 18:17, Robert Haas wrote:
>> On Tue, Apr 4, 2017 at 7:11 AM, Amit Khandekar
>> wrote:
>>> Attached updated patch v7 has the above changes.
>>
>
> Attached is the rebased patch, which resolves the above conflicts.
>
Few c
On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar wrote:
> On 4 March 2017 at 12:49, Robert Haas wrote:
>> On Thu, Mar 2, 2017 at 11:53 AM, Amit Khandekar
>> wrote:
>>> I think it does not make sense running after row triggers in case of
>>> row-movement. There is no update happened on that leaf
On 2 May 2017 at 18:17, Robert Haas wrote:
> On Tue, Apr 4, 2017 at 7:11 AM, Amit Khandekar wrote:
>> Attached updated patch v7 has the above changes.
>
> This no longer applies. Please rebase.
Thanks Robert for informing about this.
My patch has a separate function for emitting error message
On Tue, Apr 4, 2017 at 7:11 AM, Amit Khandekar wrote:
> Attached updated patch v7 has the above changes.
This no longer applies. Please rebase.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On 2017-04-07 13:55:51 -0400, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 5:54 AM, Amit Langote
> wrote:
> > Marked as ready for committer.
>
> Andres seems to have changed the status of this patch to "Needs
> review" and then, 30 seconds later, to "Waiting on author"
> there's no actual email on
On Wed, Apr 5, 2017 at 5:54 AM, Amit Langote
wrote:
> Marked as ready for committer.
Andres seems to have changed the status of this patch to "Needs
review" and then, 30 seconds later, to "Waiting on author", but
there's no actual email on the thread explaining what his concerns
were. I'm going
Hi Amit,
On 2017/04/04 20:11, Amit Khandekar wrote:
> On 3 April 2017 at 17:13, Amit Langote wrote:
On 31 March 2017 at 14:04, Amit Langote wrote:
>> How about something like:
>> For an UPDATE that causes a row to move from one partition to
>> another due the partition key being updated, the
On 3 April 2017 at 17:13, Amit Langote wrote:
> Hi Amit,
>
> Thanks for updating the patch. Since ddl.sgml got updated on Saturday,
> patch needs a rebase.
Rebased now.
>
>> On 31 March 2017 at 16:54, Amit Khandekar wrote:
>>> On 31 March 2017 at 14:04, Amit Langote
>>> wrote:
On 2017/0
Hi Amit,
Thanks for updating the patch. Since ddl.sgml got updated on Saturday,
patch needs a rebase.
> On 31 March 2017 at 16:54, Amit Khandekar wrote:
>> On 31 March 2017 at 14:04, Amit Langote
>> wrote:
>>> On 2017/03/28 19:12, Amit Khandekar wrote:
In the section 5.11 "Partitioning"
For some reason, my reply got sent to only Amit Langote instead of
reply-to-all. Below is the mail reply. Thanks Amit Langote for
bringing this to my notice.
On 31 March 2017 at 16:54, Amit Khandekar wrote:
> On 31 March 2017 at 14:04, Amit Langote wrote:
>> On 2017/03/28 19:12, Amit Khandekar w
Hi Amit,
Thanks for the updated patches.
On 2017/03/28 19:12, Amit Khandekar wrote:
> On 27 March 2017 at 13:05, Amit Khandekar wrote:
>>> Also, there are a few places in the documentation mentioning that such
>>> updates cause error,
>>> which will need to be updated. Perhaps also add some ex
On 27 March 2017 at 13:05, Amit Khandekar wrote:
>> Also, there are a few places in the documentation mentioning that such
>> updates cause error,
>> which will need to be updated. Perhaps also add some explanatory notes
>> about the mechanism (delete+insert), trigger behavior, caveats, etc.
>>
On 25 March 2017 at 01:34, Amit Khandekar wrote:
I am yet to handle all of your comments, but meanwhile , attached is
> an updated patch, that handles RETURNING.
>
> Earlier it was not working because ExecInsert() did not return any
> RETURNING clause. This is because the setup needed to create RE
Thanks Amit for your review comments. I am yet to handle all of your
comments, but meanwhile , attached is an updated patch, that handles
RETURNING.
Earlier it was not working because ExecInsert() did not return any
RETURNING clause. This is because the setup needed to create RETURNIG
projection i
Hi Amit,
Thanks for the updated patch.
On 2017/03/23 3:09, Amit Khandekar wrote:
> Attached is v2 patch which implements the above optimization.
Would it be better to have at least some new tests? Also, there are a few
places in the documentation mentioning that such updates cause error,
which
On 17 March 2017 at 16:07, Amit Khandekar wrote:
> On 6 March 2017 at 15:11, Amit Langote wrote:
>>
But that starts to sound less attractive when one realizes that
that will occur for every row that wants to move.
>>>
>>> If we manage to call ExecSetupPartitionTupleRouting() during exec
I haven't yet handled all points, but meanwhile, some of the important
points are discussed below ...
On 6 March 2017 at 15:11, Amit Langote wrote:
>
>>> But that starts to sound less attractive when one realizes that
>>> that will occur for every row that wants to move.
>>
>> If we manage to cal
Hi,
On 2017/03/02 15:23, Amit Khandekar wrote:
> On 23 February 2017 at 16:02, Amit Langote
> wrote:
>>
>>> 2. In the patch, as part of the row movement, ExecDelete() is called
>>> followed by ExecInsert(). This is done that way, because we want to
>>> have the ROW triggers on that (sub)partition
On Thu, Mar 2, 2017 at 11:53 AM, Amit Khandekar wrote:
> I think it does not make sense running after row triggers in case of
> row-movement. There is no update happened on that leaf partition. This
> reasoning can also apply to BR update triggers. But the reasons for
> having a BR trigger and AR
On 2017/02/26 4:01, David G. Johnston wrote:
> IIUC it is already possible, for those who care to do so, to get a
> serialization failure in this scenario by upgrading isolation to repeatable
> read.
Maybe, this can be added as a note in the documentation.
Thanks,
Amit
--
Sent via pgsql-hac
On 23 February 2017 at 16:02, Amit Langote
wrote:
>
>> 2. In the patch, as part of the row movement, ExecDelete() is called
>> followed by ExecInsert(). This is done that way, because we want to
>> have the ROW triggers on that (sub)partition executed. If a user has
>> explicitly created DELETE an
On Sat, Feb 25, 2017 at 11:41 PM, Greg Stark wrote:
> What I'm concerned about is that silently giving "wrong" answers in
> regular queries -- not even ones doing the partition key updates -- is
> something the user can't really manage. They have no way to rewrite
> the query to avoid the problem
On Sat, Feb 25, 2017 at 11:11 AM, Greg Stark wrote:
> On 24 February 2017 at 14:57, David G. Johnston
> wrote:
> > I dislike an error. I'd say that making partition "just work" here is
> > material for another patch. In this one an update of the partition key
> can
> > be documented as shortha
On 24 February 2017 at 14:57, David G. Johnston
wrote:
> I dislike an error. I'd say that making partition "just work" here is
> material for another patch. In this one an update of the partition key can
> be documented as shorthand for delete-returning-insert with all the
> limitations that go
On Friday, February 24, 2017, Simon Riggs wrote:
>
> 2. I know that DB2 handles this by having the user specify WITH ROW
> MOVEMENT to explicitly indicate they accept the issue and want update
> to work even with that. We could have an explicit option to allow
> that. This appears to be the only w
On Fri, Feb 24, 2017 at 3:24 PM, Simon Riggs wrote:
> I'd give the view that we cannot silently ignore this issue, bearing
> in mind the point that we're expecting partitioned tables to behave
> exactly like normal tables.
At the risk of repeating myself, I don't expect that, and I don't
think it
On 24 February 2017 at 07:02, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 2:58 PM, Amit Khandekar
> wrote:
>> I am inclined to at least have some option for the user to decide the
>> behaviour. In the future we can even consider support for walking
>> through the ctid chain across multiple relf
On Fri, Feb 24, 2017 at 1:18 PM, David G. Johnston
wrote:
> For my own sanity - the move update would complete successfully and break
> every ctid chain that it touches. Any update lined up behind it in the lock
> queue would discover their target record has been deleted and would
> experience wh
On Friday, February 24, 2017, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 2:58 PM, Amit Khandekar > wrote:
> > I am inclined to at least have some option for the user to decide the
> > behaviour. In the future we can even consider support for walking
> > through the ctid chain across multiple r
On Mon, Feb 20, 2017 at 2:58 PM, Amit Khandekar wrote:
> I am inclined to at least have some option for the user to decide the
> behaviour. In the future we can even consider support for walking
> through the ctid chain across multiple relfilenodes. But till then, we
> need to decide what default
Hi Amit,
Thanks for working on this.
On 2017/02/13 21:01, Amit Khandekar wrote:
> Currently, an update of a partition key of a partition is not allowed,
> since it requires to move the row(s) into the applicable partition.
>
> Attached is a WIP patch (update-partition-key.patch) that removes thi
On Mon, Feb 20, 2017 at 3:36 PM, Thomas Munro
wrote:
> On Thu, Feb 16, 2017 at 8:53 PM, Robert Haas wrote:
>> Generally speaking, we don't throw
>> serialization errors today at READ COMMITTED, so if we do so here,
>> that's going to be a noticeable and perhaps unwelcome change.
>
> Yes we do:
>
On Thu, Feb 16, 2017 at 8:53 PM, Robert Haas wrote:
> Generally speaking, we don't throw
> serialization errors today at READ COMMITTED, so if we do so here,
> that's going to be a noticeable and perhaps unwelcome change.
Yes we do:
https://www.postgresql.org/docs/9.6/static/transaction-iso.html
On 16 February 2017 at 20:53, Robert Haas wrote:
> On Thu, Feb 16, 2017 at 5:47 AM, Greg Stark wrote:
>> On 13 February 2017 at 12:01, Amit Khandekar wrote:
>>> There are a few things that can be discussed about :
>>
>> If you do a normal update the new tuple is linked to the old one using
>> th
On Thu, Feb 16, 2017 at 5:47 AM, Greg Stark wrote:
> On 13 February 2017 at 12:01, Amit Khandekar wrote:
>> There are a few things that can be discussed about :
>
> If you do a normal update the new tuple is linked to the old one using
> the ctid forming a chain of tuple versions. This tuple move
On Thu, Feb 16, 2017 at 03:39:30PM +0530, Amit Khandekar wrote:
> 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
On 13 February 2017 at 12:01, Amit Khandekar wrote:
> There are a few things that can be discussed about :
If you do a normal update the new tuple is linked to the old one using
the ctid forming a chain of tuple versions. This tuple movement breaks
that chain. So the question I had reading this
On 16 February 2017 at 14:42, Amit Langote
wrote:
> On 2017/02/16 17:55, Amit Khandekar wrote:
>> On 16 February 2017 at 12:57, Amit Langote wrote:
>>> On 2017/02/16 15:50, Amit Khandekar wrote:
On 15 February 2017 at 20:26, David Fetter wrote:
> Does that make sense, and if so, is it su
On 2017/02/16 17:55, Amit Khandekar wrote:
> On 16 February 2017 at 12:57, Amit Langote wrote:
>> On 2017/02/16 15:50, Amit Khandekar wrote:
>>> On 15 February 2017 at 20:26, David Fetter wrote:
Does that make sense, and if so, is it super invasive to HINT that?
>>>
>>> Yeah, I think it shoul
On 16 February 2017 at 12:57, Amit Langote
wrote:
> On 2017/02/16 15:50, Amit Khandekar wrote:
>> On 15 February 2017 at 20:26, David Fetter 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 wo
On 2017/02/16 15:50, Amit Khandekar wrote:
> On 15 February 2017 at 20:26, David Fetter 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
On 15 February 2017 at 20:26, David Fetter 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 candida
On Wed, Feb 15, 2017 at 01:06:32PM +0530, Amit Khandekar wrote:
> On 14 February 2017 at 22:24, David Fetter wrote:
> > On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote:
> >> Currently, an update of a partition key of a partition is not
> >> allowed, since it requires to move the row
On 14 February 2017 at 22:24, David Fetter wrote:
> On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote:
>> Currently, an update of a partition key of a partition is not
>> allowed, since it requires to move the row(s) into the applicable
>> partition.
>>
>> Attached is a WIP patch (upd
On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote:
> Currently, an update of a partition key of a partition is not
> allowed, since it requires to move the row(s) into the applicable
> partition.
>
> Attached is a WIP patch (update-partition-key.patch) that removes
> this restriction.
On Mon, Feb 13, 2017 at 7:01 AM, Amit Khandekar wrote:
> partspartitioned inheritance no. of rows subpartitions
> ==== === === =
>
> 500 10 sec 3 min 02 sec 1,000,000 0
> 1000 10 sec 3 min 05 sec 1,000,000
Currently, an update of a partition key of a partition is not allowed,
since it requires to move the row(s) into the applicable partition.
Attached is a WIP patch (update-partition-key.patch) that removes this
restriction. When an UPDATE causes the row of a partition to violate
its partition const
101 - 181 of 181 matches
Mail list logo
