Re: [HACKERS] Parallel Append implementation

2017-11-12 Thread Amit Khandekar
Thanks a lot Robert for the patch. I will have a look. Quickly tried to test some aggregate queries with a partitioned pgbench_accounts table, and it is crashing. Will get back with the fix, and any other review comments. Thanks -Amit Khandekar On 9 November 2017 at 23:44, Robert Haas <rober

Re: [HACKERS] UPDATE of partition key

2017-11-09 Thread Amit Khandekar
On 9 November 2017 at 09:27, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, Nov 8, 2017 at 5:57 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> On 8 November 2017 at 07:55, Thomas Munro <thomas.mu...@enterprisedb.com> >> wrote: >>> O

Re: [HACKERS] UPDATE of partition key

2017-11-07 Thread Amit Khandekar
remental patch regress_locale_changes.patch and check if the test passes ? The patch is to be applied on the main v22 patch. If the test passes, I will include these changes (also for list_parted) in the upcoming v23 patch. Thanks -Amit Khandekar regress_locale_changes.patch Description: Bin

Re: [HACKERS] UPDATE of partition key

2017-11-06 Thread Amit Khandekar
these arrays into one, but we are adding a new int[] array that maps subplans to leaf partitions. Will get back with how it looks finally. Robert, Amit , I will get back with your other review comments. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via p

Re: [HACKERS] Parallel Append implementation

2017-10-19 Thread Amit Khandekar
On 13 October 2017 at 00:29, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Oct 11, 2017 at 8:51 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> [ new patch ] > > + parallel_append > + Waiting to choose the next subpl

Re: [HACKERS] pgsql: Avoid coercing a whole-row variable that is already coerced

2017-10-13 Thread Amit Khandekar
ciency and beautification hack. I'm not sure whether this case ever arises currently, but the pending patch for update tuple routing will cause it to arise. Amit Khandekar Discussion: http://postgr.es/m/caj3gd9cazfppe7-wwubabpcq4_0subkipfd1+0r5_dkvnwo...@mail.gmail.com Tom Lan

Re: [HACKERS] Parallel Append implementation

2017-10-11 Thread Amit Khandekar
On 9 October 2017 at 16:03, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Oct 6, 2017 at 12:03 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 6 October 2017 at 08:49, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> >>> Okay,

Re: [HACKERS] Parallel Append implementation

2017-10-06 Thread Amit Khandekar
On 6 October 2017 at 08:49, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Oct 5, 2017 at 4:11 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> >> Ok. How about removing pa_all_partial_subpaths altogether , and >> instead of the below condition : &g

Re: [HACKERS] Parallel Append implementation

2017-10-05 Thread Amit Khandekar
On 30 September 2017 at 19:21, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Sep 20, 2017 at 10:59 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 16 September 2017 at 10:42, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> >>> A

Re: [HACKERS] UPDATE of partition key

2017-10-03 Thread Amit Khandekar
On 30 September 2017 at 01:26, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 29, 2017 at 3:53 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Sep 22, 2017 at 1:57 AM, Amit Khandekar <amitdkhan...@gmail.com> >> wrote: >>> The patch

Re: [HACKERS] Parallel Append implementation

2017-09-28 Thread Amit Khandekar
On 20 September 2017 at 11:32, Amit Khandekar <amitdkhan...@gmail.com> wrote: > There is still the open point being > discussed : whether to have non-parallel-aware partial Append path, or > always have parallel-aware Append paths. Attached is the revised patch v16. In previous ve

Re: [HACKERS] UPDATE of partition key

2017-09-28 Thread Amit Khandekar
ns. There are no indexed columns. UPDATE query used : UPDATE ptab set a = a + '2 years'::interval ; [1] https://drive.google.com/open?id=0B_YJCqIAxKjeN3hMXzdDejlNYmlpWVJpaU9mWUhFRVhXTG5Z -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company gen.tar.gz Descr

Re: [HACKERS] UPDATE of partition key

2017-09-22 Thread Amit Khandekar
On 21 September 2017 at 19:52, amul sul <sula...@gmail.com> wrote: > On Wed, Sep 20, 2017 at 9:27 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> >> On 20 September 2017 at 00:06, Robert Haas <robertmh...@gmail.com> wrote: >> > On Fri, Sep 1

Re: [HACKERS] UPDATE of partition key

2017-09-20 Thread Amit Khandekar
On 20 September 2017 at 00:06, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 15, 2017 at 7:25 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> [ new patch ] > > This already fails to apply again. In general, I think it would be a > good idea to

Re: [HACKERS] Parallel Append implementation

2017-09-20 Thread Amit Khandekar
gt; static void > add_paths_to_append_rel() > Added comments. Attached revised patch v15. There is still the open point being discussed : whether to have non-parallel-aware partial Append path, or always have parallel-aware Append paths. -- Thanks, -Amit Khandekar EnterpriseDB Corporation T

Re: [HACKERS] Parallel Append implementation

2017-09-19 Thread Amit Khandekar
. Otherwise, if we try to come up with a common logic that conditionally chooses different next plan for leader or worker, then that logic would most probably get complicated than the current state. Also, I don't see any performance issue if there is a leader is running backwards while the others

Re: [HACKERS] UPDATE of partition key

2017-09-19 Thread Amit Khandekar
PartitionWalker; > + > > Same as above Yes, this was left out from the earlier implementation. Will have this removed in the next updated patch. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parallel Append implementation

2017-09-17 Thread Amit Khandekar
On 16 September 2017 at 11:45, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Sep 14, 2017 at 8:30 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 11 September 2017 at 18:55, Amit Kapila <amit.kapil...@gmail.com> wrote: >>>> >>&g

Re: [HACKERS] Parallel Append implementation

2017-09-14 Thread Amit Khandekar
place, then non-parallel-aware partial Append is out of question, which we both agree. And the other case where we skip non-parallel-aware partial Append is when all the cheapest subpaths of the parallel-aware Append path are partial paths: we do not want parallel-aware and non-parallel-aware A

Re: [HACKERS] expanding inheritance in partition bound order

2017-09-14 Thread Amit Khandekar
leaf oids are ordered exaclty in the order of the UPDATE subplans output. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] expanding inheritance in partition bound order

2017-09-13 Thread Amit Khandekar
the decoupling later for some reason, we can do that incrementally. Will review your latest patch by tomorrow. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-09-13 Thread Amit Khandekar
On 13 September 2017 at 13:05, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Sep 13, 2017 at 12:32 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> Hi, >> >> Rafia had done some testing on TPCH queries using Partition-wise join >&

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-09-13 Thread Amit Khandekar
Hi, Rafia had done some testing on TPCH queries using Partition-wise join patch along with Parallel Append patch. There, we had observed that for query 4, even though the partition wise joins are under a Parallel Append, the join are all non-partial. Specifically, the partition-wise join has

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-12 Thread Amit Khandekar
generate_gather_paths(root, rel); + if (rel->reloptkind == RELOPT_BASEREL && root->simple_rel_array_size > 2) + generate_gather_paths(root, rel, NULL); Above, in case it's a partitioned table, root->simple_rel_array_size includes the child rels. So even if i

Re: [HACKERS] UPDATE of partition key

2017-09-12 Thread Amit Khandekar
On 12 September 2017 at 11:57, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Tue, Sep 12, 2017 at 11:15 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: > >> But the statement level trigger function can refer to OLD TABLE and >> NEW TABLE, which will cont

Re: [HACKERS] UPDATE of partition key

2017-09-11 Thread Amit Khandekar
On 11 September 2017 at 21:12, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Thu, Sep 7, 2017 at 11:41 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 6 September 2017 at 21:47, Dilip Kumar <dilipbal...@gmail.com> wrote: > >> Actually, since t

Re: [HACKERS] Parallel Append implementation

2017-09-11 Thread Amit Khandekar
On 8 September 2017 at 19:17, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Sep 8, 2017 at 3:59 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> On 7 September 2017 at 11:05, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> On Thu, Aug 31, 2017 at

Re: [HACKERS] expanding inheritance in partition bound order

2017-09-11 Thread Amit Khandekar
orresponding to the internal partitions are multiplied by" anywhere in the patch. I think those comments are still valid, and important. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Parallel Append implementation

2017-09-08 Thread Amit Khandekar
On 7 September 2017 at 11:05, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Aug 31, 2017 at 12:47 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> The last updated patch needs a rebase. Attached is the rebased version. >> > > Few comments on

Re: [HACKERS] UPDATE of partition key

2017-09-07 Thread Amit Khandekar
On 3 September 2017 at 17:10, Amit Khandekar <amitdkhan...@gmail.com> wrote: > After recent commit 30833ba154, now the partitions are expanded in > depth-first order. It didn't seem worthwhile rebasing my partition > walker changes onto the latest code. So in the attached patch, I

Re: [HACKERS] Parallel Append implementation

2017-09-07 Thread Amit Khandekar
On 7 September 2017 at 13:40, Rafia Sabih <rafia.sa...@enterprisedb.com> wrote: > On Wed, Aug 30, 2017 at 5:32 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> Hi Rafia, >> >> On 17 August 2017 at 14:12, Amit Khandekar <amitdkhan...@gmail.com>

Re: [HACKERS] Parallel Append implementation

2017-09-05 Thread Amit Khandekar
On 30 August 2017 at 17:32, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 16 August 2017 at 18:34, Robert Haas <robertmh...@gmail.com> wrote: >> Thanks for the benchmarking results! >> >> On Tue, Aug 15, 2017 at 11:35 PM, Rafia Sabih >> <rafia.sa...@

Re: [HACKERS] expanding inheritance in partition bound order

2017-09-04 Thread Amit Khandekar
On 4 September 2017 at 06:34, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Hi Amit, > > On 2017/09/03 16:07, Amit Khandekar wrote: >> On 31 August 2017 at 13:06, Amit Langote <langote_amit...@lab.ntt.co.jp> >> wrote: >>>> Mind you, t

Re: [HACKERS] UPDATE of partition key

2017-09-03 Thread Amit Khandekar
On 31 August 2017 at 14:15, Amit Khandekar <amitdkhan...@gmail.com> wrote: > Thanks Dilip. I am working on rebasing the patch. Particularly, the > partition walker in my patch depended on the fact that all the tables > get opened (and then closed) while creating the tup

Re: [HACKERS] expanding inheritance in partition bound order

2017-09-03 Thread Amit Khandekar
On 31 August 2017 at 13:06, Amit Langote wrote: >> Mind you, that idea has some problems anyway in the face of default >> partitions, null partitions, and list partitions which accept >> non-contiguous values (e.g. one partition for 1, 3, 5; another for 2, >> 4, 6).

Re: [HACKERS] UPDATE of partition key

2017-08-31 Thread Amit Khandekar
-b906-dec040a206f2%40lab.ntt.co.jp On 31 August 2017 at 12:09, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Fri, Aug 11, 2017 at 10:44 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 4 August 2017 at 22:28, Amit Khandekar <amitdkhan...@gmail.com> wrote: &g

Re: [HACKERS] Parallel Append implementation

2017-08-31 Thread Amit Khandekar
The last updated patch needs a rebase. Attached is the rebased version. Thanks -Amit Khandekar ParallelAppend_v13_rebased_3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Parallel Append implementation

2017-08-30 Thread Amit Khandekar
Hi Rafia, On 17 August 2017 at 14:12, Amit Khandekar <amitdkhan...@gmail.com> wrote: > But for all of the cases here, partial > subplans seem possible, and so even on HEAD it executed Partial > Append. So between a Parallel Append having partial subplans and a > Partial App

Re: [HACKERS] expanding inheritance in partition bound order

2017-08-30 Thread Amit Khandekar
On 25 August 2017 at 23:58, Robert Haas wrote: > > That just leaves indexes. In a world where keystate, tupslot, and > tupmap are removed from the PartitionDispatchData, you must need > indexes or there would be no point in constructing a > PartitionDispatchData object in

Re: [HACKERS] expanding inheritance in partition bound order

2017-08-18 Thread Amit Khandekar
artitionDispatchData though, because it's essentially free to create > while we are walking the partition tree in > RelationGetPartitionDispatchInfo() and it seems undesirable to make the > caller compute that information (indexes) by traversing the partition tree > all over again, if

Re: [HACKERS] expanding inheritance in partition bound order

2017-08-17 Thread Amit Khandekar
-weight function to just generate oids, and keep RelationGetPartitionDispatchInfo() intact, to be used only for tuple routing. But, I haven't yet checked Ashuthosh's requirements, which suggest that it does not help to even get the oid list. > > -- > Robert Haas > EnterpriseDB: http:

Re: [HACKERS] expanding inheritance in partition bound order

2017-08-17 Thread Amit Khandekar
On 17 August 2017 at 06:39, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Hi Amit, > > Thanks for the comments. > > On 2017/08/16 20:30, Amit Khandekar wrote: >> On 16 August 2017 at 11:06, Amit Langote <langote_amit...@lab.ntt.co.jp> >>

Re: [HACKERS] Parallel Append implementation

2017-08-17 Thread Amit Khandekar
even possible that the performance gain might be due to some other reasons. I will investigate this, and the other queries. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] expanding inheritance in partition bound order

2017-08-16 Thread Amit Khandekar
ited_rtentry(), we traverse the partition tree using these descriptors similar to how it is traversed in RelationGetPartitionDispatchInfo() ? May be to avoid code duplication for traversing, we can have a common API. Still looking at RelationGetPartitionDispatchInfo() changes ... -- Thanks, -

Re: [HACKERS] Parallel Append implementation

2017-08-09 Thread Amit Khandekar
On 9 August 2017 at 19:05, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jul 5, 2017 at 7:53 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >>> This is not applicable on the latest head i.e. commit -- >>> 08aed6604de2e6a9f4d499818d7c641cbf5eb9f7, looks l

Re: [HACKERS] expanding inheritance in partition bound order

2017-08-06 Thread Amit Khandekar
le plan; the PartitionDispatch data structure returned by RelationGetPartitionDispatchInfo() should be stored in that plan, and then the execution-time fields in PartitionDispatch would be populated in ExecInitModifyTable(). -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Data

Re: [HACKERS] UPDATE of partition key

2017-08-04 Thread Amit Khandekar
> > Below are the TODOS at this point : > > Fix for bug reported by Rajkumar about update with join. I had explained the root issue of this bug here : [1] Attached patch includes the fix, which is explained below. Currently in the patch, there is a check if the tuple is concurrently deleted by

Re: [HACKERS] map_partition_varattnos() and whole-row vars

2017-08-02 Thread Amit Khandekar
On 3 August 2017 at 11:00, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Thanks for the review. > > On 2017/08/03 13:54, Amit Khandekar wrote: >> On 2 August 2017 at 11:51, Amit Langote wrote: >>> On 2017/08/02 1:33, Amit Khandekar wrote: >>>> Ins

Re: [HACKERS] map_partition_varattnos() and whole-row vars

2017-08-02 Thread Amit Khandekar
On 2 August 2017 at 11:51, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Thanks Fuita-san and Amit for reviewing. > > On 2017/08/02 1:33, Amit Khandekar wrote: >> On 1 August 2017 at 15:11, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: >>> On

Re: [HACKERS] UPDATE of partition key

2017-08-02 Thread Amit Khandekar
On 2 August 2017 at 14:38, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/07/29 2:45, Amit Khandekar wrote: >> On 28 July 2017 at 20:10, Robert Haas <robertmh...@gmail.com> wrote: >>> On Wed, Jul 26, 2017 at 2:13 AM, Amit Langote wrote: >>>

Re: [HACKERS] map_partition_varattnos() and whole-row vars

2017-08-01 Thread Amit Khandekar
if (found_whole_row) + elog(ERROR, "unexpected whole-row reference found in partition key"); Instead of callers of map_partition_varattnos() reporting error, we can have map_partition_varattnos() itself report error. Instead of the found_whole_row parameter of map_partition_varattnos(), we can have error_on_whole_row parameter. So callers who don't expect whole row, would pass error_on_whole_row=true to map_partition_varattnos(). This will simplify the resultant code a bit. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] UPDATE of partition key

2017-07-28 Thread Amit Khandekar
ate) while inserting a routed tuple. Use getASTriggerResultRelInfo() for attrno mapping, rather than first resultrel, for generating child WCO/RETURNING expression. Address Robert's review comments on make_resultrel_ordered.patch. pgindent. [1] https://www.postgresql.org/message-id/d86d27ea-cc9d-5

Re: [HACKERS] map_partition_varattnos() and whole-row vars

2017-07-28 Thread Amit Khandekar
RETURNING) can have a subquery. > > Thanks, > Amit > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Thanks, -Amit Khandekar EnterpriseDB Corporat

Re: [HACKERS] UPDATE of partition key

2017-07-26 Thread Amit Khandekar
ionGetPartitionDispatchInfo(). > On another note, did you do anything about the suggestion Thomas made > in > http://postgr.es/m/CAEepm=3sc_j1zwqdyrbu4dtfx5rhcamnnuaxrkwzfgt9m23...@mail.gmail.com > ? This is still pending on me; plus I think there are some more points. I need to go over

Re: [HACKERS] UPDATE of partition key

2017-07-25 Thread Amit Khandekar
On 25 July 2017 at 15:02, Rajkumar Raghuwanshi <rajkumar.raghuwan...@enterprisedb.com> wrote: > On Mon, Jul 24, 2017 at 11:23 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> >> >> Attached update-partition-key_v13.patch now contains this >> make_

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

2017-07-24 Thread Amit Khandekar
On 24 July 2017 at 12:11, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Hi Amit, > > On 2017/07/24 14:09, Amit Khandekar wrote: >>>> On 2017/07/10 14:15, Etsuro Fujita wrote: >>>> Another thing I noticed is the error handling in ExecWithChec

Re: [HACKERS] UPDATE of partition key

2017-07-23 Thread Amit Khandekar
On 13 July 2017 at 22:39, Amit Khandekar <amitdkhan...@gmail.com> wrote: > Attached is a WIP patch (make_resultrels_ordered.patch) that generates > the result rels in canonical order. This patch is kept separate from > the update-partition-key patch, and can be applied on master br

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

2017-07-23 Thread Amit Khandekar
he row in the error message emitted for the WithCheckOption violation. Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company set_slot_descriptor.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] UPDATE of partition key

2017-07-13 Thread Amit Khandekar
On 5 July 2017 at 15:12, Amit Khandekar <amitdkhan...@gmail.com> wrote: > Like I mentioned upthread... in expand_inherited_rtentry(), if we > replace find_all_inheritors() with something else that returns oids in > canonical order, that will change the order in which children tabl

Re: [HACKERS] Parallel Append implementation

2017-07-05 Thread Amit Khandekar
On 30 June 2017 at 15:10, Rafia Sabih <rafia.sa...@enterprisedb.com> wrote: > > On Tue, Apr 4, 2017 at 12:37 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> >> Attached is an updated patch v13 that has some comments changed as per >> your re

Re: [HACKERS] UPDATE of partition key

2017-07-05 Thread Amit Khandekar
On 4 July 2017 at 15:23, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 4 July 2017 at 14:48, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> On 4 July 2017 at 14:38, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >>> On 2017/07/04 17:25, Etsuro Fu

Re: [HACKERS] UPDATE of partition key

2017-07-04 Thread Amit Khandekar
On 4 July 2017 at 14:48, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 4 July 2017 at 14:38, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> On 2017/07/04 17:25, Etsuro Fujita wrote: >>> On 2017/07/03 18:54, Amit Langote wrote: >>>&

Re: [HACKERS] UPDATE of partition key

2017-07-04 Thread Amit Khandekar
efactor it completely. find_inheritance_children() needs to return the oids in canonical order. So in find_inheritance_children () need to re-use part of RelationBuildPartitionDesc() where it generates those oids in that order. I am checking this part, and am going to come up with an approach based on findi

Re: [HACKERS] UPDATE of partition key

2017-06-29 Thread Amit Khandekar
above: If we don't find any updated partition-keys in any of them, well and good. If we do find, failover to approach 3 : For each of the update resultrels, use the new rd_partcheckattrs bitmap to know if it uses any of the updated columns. This would be faster than pulling up attrs from the qua

Re: [HACKERS] UPDATE of partition key

2017-06-29 Thread Amit Khandekar
On 29 June 2017 at 07:42, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > Hi Amit, > > On 2017/06/28 20:43, Amit Khandekar wrote: >> In attached patch v12 > > The patch no longer applies and fails to compile after the following > commit

Re: [HACKERS] UPDATE of partition key

2017-06-28 Thread Amit Khandekar
On 22 June 2017 at 01:57, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jun 21, 2017 at 1:38 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >>>> Yep, it's more appropriate to use >>>> ModifyTableState->rootResultRelationInfo->r

Re: [HACKERS] UPDATE of partition key

2017-06-28 Thread Amit Khandekar
On 26 June 2017 at 08:37, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 22 June 2017 at 01:41, Robert Haas <robertmh...@gmail.com> wrote: >>>> Second, it will amount to a functional bug if you get a >>>> different answer than the planner did. >&g

Re: [HACKERS] UPDATE of partition key

2017-06-25 Thread Amit Khandekar
On 22 June 2017 at 01:41, Robert Haas wrote: >>> Second, it will amount to a functional bug if you get a >>> different answer than the planner did. >> >> Actually, the per-leaf WCOs are meant to be executed on the >> destination partitions where the tuple is moved, while

Re: [HACKERS] UPDATE of partition key

2017-06-21 Thread Amit Khandekar
ken? If it works >>> for some reason, the comments don't explain what that reason is. >> >> Yep, it's more appropriate to use >> ModifyTableState->rootResultRelationInfo->ri_RelationDesc somehow. That >> is, if answer to the question I raised above is positiv

Re: [HACKERS] UPDATE of partition key

2017-06-21 Thread Amit Khandekar
On 21 June 2017 at 00:23, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jun 20, 2017 at 2:54 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >>> I guess I don't see why it should work like this. In the INSERT case, >>> we must build withCheckOptio

Re: [HACKERS] UPDATE of partition key

2017-06-20 Thread Amit Khandekar
On 20 June 2017 at 03:46, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jun 15, 2017 at 1:36 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> Attached patch v10 fixes the above. In the existing code, where it >> builds WCO constraints for each

Re: [HACKERS] UPDATE of partition key

2017-06-19 Thread Amit Khandekar
istent with the existing code. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] UPDATE of partition key

2017-06-18 Thread Amit Khandekar
oc0(sizeof(TupleConversionMap*) * nplans); On 15 June 2017 at 23:06, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 13 June 2017 at 15:40, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> While rebasing my patch for the below recent commit, I realized that a >>

Re: [HACKERS] UPDATE of partition key

2017-06-15 Thread Amit Khandekar
On 13 June 2017 at 15:40, Amit Khandekar <amitdkhan...@gmail.com> wrote: > While rebasing my patch for the below recent commit, I realized that a > similar issue exists for the uptate-tuple-routing patch as well : > > commit 78a030a441966d91bc7e932ef84da39c3ea7d970 >

Re: [HACKERS] UPDATE of partition key

2017-06-13 Thread Amit Khandekar
While rebasing my patch for the below recent commit, I realized that a similar issue exists for the uptate-tuple-routing patch as well : commit 78a030a441966d91bc7e932ef84da39c3ea7d970 Author: Tom Lane Date: Mon Jun 12 23:29:44 2017 -0400 Fix confusion about number of

Re: [HACKERS] UPDATE of partition key

2017-06-09 Thread Amit Khandekar
ks and change them to use >>>> some other method to conclude that the row is deleted. What method >>>> would we use? >>> >>> I think before doing above check we can simply check if ctid.ip_blkid >>> contains InvalidBlockNumber, then return an err

Re: [HACKERS] strcmp() tie-breaker for identical ICU-collated strings

2017-06-09 Thread Amit Khandekar
On 2 June 2017 at 23:52, Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Jun 2, 2017 at 10:34 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> Ok. I was thinking we are doing the tie-breaker because specifically >> strcoll_l() was unexpectedly returni

Re: [HACKERS] UPDATE of partition key

2017-06-08 Thread Amit Khandekar
On 7 June 2017 at 20:19, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 7 June 2017 at 16:42, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> The column bitmap set returned by GetUpdatedColumns() refer to >> attribute numbers w.r.t. to the root partition. And t

Re: [HACKERS] UPDATE of partition key

2017-06-07 Thread Amit Khandekar
On 7 June 2017 at 16:42, Amit Khandekar <amitdkhan...@gmail.com> wrote: > The column bitmap set returned by GetUpdatedColumns() refer to > attribute numbers w.r.t. to the root partition. And the > mstate->resultRelInfo[] have attnos w.r.t. to the leaf partitions. So > we

Re: [HACKERS] UPDATE of partition key

2017-06-07 Thread Amit Khandekar
On 6 June 2017 at 23:52, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jun 2, 2017 at 7:07 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> So, according to that, below would be the logic : >> >> Run partition constraint check on the or

Re: [HACKERS] UPDATE of partition key

2017-06-05 Thread Amit Khandekar
On 5 June 2017 at 11:27, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Jun 2, 2017 at 4:37 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> On 2 June 2017 at 01:17, Robert Haas <robertmh...@gmail.com> wrote: >>> On Thu, Jun 1, 2017 at 7:41 AM, Am

Re: [HACKERS] strcmp() tie-breaker for identical ICU-collated strings

2017-06-02 Thread Amit Khandekar
case, there might be many characters considered equal, but PG < operator or > operator would still return true for those chars. -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] UPDATE of partition key

2017-06-02 Thread Amit Khandekar
On 2 June 2017 at 01:17, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jun 1, 2017 at 7:41 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >>> Regarding the trigger issue, I can't claim to have a terribly strong >>> opinion on this. I think that prac

[HACKERS] strcmp() tie-breaker for identical ICU-collated strings

2017-06-01 Thread Amit Khandekar
by intention. That's the reason I feel like the strcmp-if-strtoll-returns-0 thing might not be applicable for ICU. But I may be wrong, please correct me if I may be missing something. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers

Re: [HACKERS] UPDATE of partition key

2017-06-01 Thread Amit Khandekar
return NULL; > > I don't understand the motivation for this change, and there are no > comments explaining it that I can see. Yeah comments, I think, are missing. I thought in the ExecDelete() they are there, but they are not. If a concurrent delete already deleted the row, we should not

Re: [HACKERS] UPDATE of partition key

2017-05-28 Thread Amit Khandekar
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

2017-05-24 Thread Amit Khandekar
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

2017-05-24 Thread Amit Khandekar
leaf partitions. And then when an update causes row movement, using option 3 would end up not firing update triggers on any of the partitions. So, I prefer option 2 over option 3 , i.e. make sure to fire BR and AR update triggers. Actually option 2 is what Robert had proposed in the beginning. -- Tha

Re: [HACKERS] UPDATE of partition key

2017-05-18 Thread Amit Khandekar
On 17 May 2017 at 17:29, Rushabh Lathia <rushabh.lat...@gmail.com> wrote: > > > On Wed, May 17, 2017 at 12:06 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: >> >> On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar <amitdkhan...@gmail.com> >> wrote: >&g

Re: [HACKERS] UPDATE of partition key

2017-05-12 Thread Amit Khandekar
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

2017-05-11 Thread Amit Khandekar
lt partition, it moves into that partition. I think we can debate on whether the row should stay in the default partition or move. I think it should be moved, since now the row has a suitable partition. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent v

Re: [HACKERS] UPDATE of partition key

2017-05-11 Thread Amit Khandekar
On 12 May 2017 at 08:30, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 11 May 2017 at 17:23, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> On Fri, Mar 17, 201

Re: [HACKERS] UPDATE of partition key

2017-05-11 Thread Amit Khandekar
On 12 May 2017 at 10:01, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, May 12, 2017 at 9:27 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar <amitdkhan...@gmail.com> >> wrote: >>> On 11

Re: [HACKERS] UPDATE of partition key

2017-05-11 Thread Amit Khandekar
n't such a partition, an error will occur. > > Doesn't this error case indicate that this needs to be integrated with > Default partition patch of Rahila or that patch needs to take care > this error case? > Basically, if there is no matching partition, then move it to default > partition. W

Re: [HACKERS] UPDATE of partition key

2017-05-11 Thread Amit Khandekar
On 11 May 2017 at 17:23, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 4 March 2017 at 12:49, Robert Haas <robertmh...@gmail.com> wrote: >>> On Thu, Mar 2, 2017

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

2017-05-05 Thread Amit Khandekar
cks, say : w1 : 1, 5, 9, 13 w2 : 2, 6, 10, 14 w3 : 3, 7, 11, 15. w4 : . May be the leader worker would do the accounting and store the instructions for each of the workers at individual locations in shared memory, so there won't be any contention while accessing them. This may be simple

Re: [HACKERS] UPDATE of partition key

2017-05-02 Thread Amit Khandekar
On 2 May 2017 at 18:17, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Apr 4, 2017 at 7:11 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> Attached updated patch v7 has the above changes. > > This no longer applies. Please rebase. Thanks Robert for informin

Re: [HACKERS] Declarative partitioning - another take

2017-04-26 Thread Amit Khandekar
but if you operate on the parent, > only the parent's triggers fire. I would also opt for this behaviour. Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Parallel Append implementation

2017-04-18 Thread Amit Khandekar
On 7 April 2017 at 20:35, Andres Freund wrote: >> But for costs such as (4, 4, 4, 20 times), the logic would give >> us 20 workers because we want to finish the Append in 4 time units; >> and this what we want to avoid when we go with >> don't-allocate-too-many-workers

Re: [HACKERS] Parallel Append implementation

2017-04-07 Thread Amit Khandekar
On 6 April 2017 at 07:33, Andres Freund <and...@anarazel.de> wrote: > On 2017-04-05 14:52:38 +0530, Amit Khandekar wrote: >> This is what the earlier versions of my patch had done : just add up >> per-subplan parallel_workers (1 for non-partial subplan and >> subpath-&g

  1   2   >