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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
. 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
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
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
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
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
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
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
>&
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
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
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
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
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
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
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
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
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>
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...@
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
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
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).
-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
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
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
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
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
-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:
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>
>>
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
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,
-
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
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
>
> 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
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
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
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:
>>>
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
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
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
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
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_
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
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
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
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
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
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
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:
>>>&
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
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
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
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
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
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
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
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
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
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
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
>>
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
>
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
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
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
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
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
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
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
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
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
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
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
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] -
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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 - 100 of 194 matches
Mail list logo