Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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 >>>

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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] >>> >> >>

Re: [HACKERS] UPDATE of partition key

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] - >

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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. > > >

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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 >>

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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. >> >>

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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.

Re: [HACKERS] UPDATE of partition key

>> 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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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)

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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. >> > >

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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.

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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 >

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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 >

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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:

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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? >>> >>>

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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

<    1   2