On 2017/09/10 15:22, Michael Paquier wrote:
> On Sun, Sep 10, 2017 at 3:15 PM, Amit Kapila wrote:
>> On Sat, Sep 9, 2017 at 9:00 PM, Tom Lane wrote:
>>> Michael Paquier writes:
On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane wrote:
> In short, this patch needs a significant rewrite, and more
On 2017/09/09 9:58, Robert Haas wrote:
> I'm a bit suspicious about the fact that there are now executor
> changes related to the PlanRowMarks. If the rowmark's prti is now the
> intermediate parent's RT index rather than the top-parent's RT index,
> it'd seem like that'd matter somehow. Maybe it
On 2017/09/09 2:38, Ashutosh Bapat wrote:
> On Fri, Sep 8, 2017 at 11:17 AM, Amit Langote wrote:
>> I updated the patch to include just those changes. I'm not sure about
>> one of the Ashutosh's changes whereby the child PlanRowMark is also passed
>> to expand_part
On 2017/09/05 14:11, Amit Khandekar wrote:
> Great, thanks. Just wanted to make sure someone is working on that,
> because, as you said, it is no longer an EIBO patch. Since you are
> doing that, I won't work on that.
Here is that patch (actually two patches). Sorry it took me a bit.
Description
On 2017/09/08 18:57, Robert Haas wrote:
>> As mentioned by Amit Langote in the above mail thread, he is going to
>> do changes for making RelationGetPartitionDispatchInfo() return the
>> leaf partitions in depth-first order. Once that is done, I will then
>> remove t
On 2017/09/08 4:41, Robert Haas wrote:
> On Thu, Sep 7, 2017 at 7:16 AM, Amit Langote
> wrote:
>> There is a patch in the Ashutosh's posted series of patches, which does
>> more or less the same thing that this patch does. He included it in his
>> series of pat
On 2017/09/08 14:47, Amit Langote wrote:
> When I tried the attached patch, it doesn't seem to expand partitioning
> inheritance in step-wise manner as the patch's title says.
Oops. By "attached patch", I had meant to say the Robert's patch, that
is, expand-
On 2017/09/08 4:04, Robert Haas wrote:
> On Tue, Sep 5, 2017 at 7:01 AM, Ashutosh Bapat
> wrote:
>> accumulate_append_subpath() is executed for every path instead of
>> every relation, so changing it would collect the same list multiple
>> times. Instead, I found the old way of associating all int
Forgot to mention a couple of important points about the relation of some
of the patches here to the patches and discussion at the
partitionwise-join thread [1].
On 2017/09/06 19:38, Amit Langote wrote:
> [PATCH 1/5] Expand partitioned inheritance in a non-flattened manner
>
> This will
On 2017/09/07 13:09, Michael Paquier wrote:
> On Thu, Sep 7, 2017 at 12:59 PM, Tom Lane wrote:
>> The idea I'd had was to apply the masking only if pd_lower >=
>> SizeOfPageHeaderData, or if you wanted to be stricter, only if
>> pd_lower != 0.
>
> If putting a check, it seems to me that the stric
On 2017/09/07 8:51, Michael Paquier wrote:
> On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote:
>> Amit Langote writes:
>>> On 2017/08/22 9:39, Michael Paquier wrote:
>>>> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote
>>>> wrote:
>>>>> I u
On 2017/09/04 10:10, Amit Langote wrote:
> On 2017/09/02 2:52, Robert Haas wrote:
>> It strikes me that this patch set is doing two things but maybe in the
>> opposite order that I would have chosen to attack them. First,
>> there's getting partition pruning t
On 2017/09/06 18:46, Rushabh Lathia wrote:
> Okay, I have marked this as ready for committer.
Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks
good to me too.
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On 2017/09/05 21:14, Tom Lane wrote:
> Amit Langote writes:
>> On 2017/09/05 15:48, Etsuro Fujita wrote:
>>> Here is the copyright in partition.h:
>>>
>>> * Copyright (c) 2007-2017, PostgreSQL Global Development Group
>>>
>>> I think it'
On 2017/09/05 15:43, Ashutosh Bapat wrote:
> Ok. Can you please answer my previous questions?
>
> AFAIU, the list contained RTIs of the relations, which didnt' have
> corresponding AppendRelInfos to lock those relations. Now that we
> create AppendRelInfos even for partitioned partitions with my 0
On 2017/09/05 15:48, Etsuro Fujita wrote:
> Here is the copyright in partition.h:
>
> * Copyright (c) 2007-2017, PostgreSQL Global Development Group
>
> I think it's reasonable that that matches the copyright in partition.c,
> but partition.c has:
>
> * Portions Copyright (c) 1996-2017, Postgr
On 2017/09/05 15:30, Ashutosh Bapat wrote:
> Those changes are already part of my updated 0001 patch. Aren't they?
> May be you should just review those and see if those are suitable for
> you?
Yeah, I think it's going to be the same patch, functionality-wise.
And sorry, I didn't realize you were
On 2017/09/05 13:20, Amit Langote wrote:
> The later phase can
> build that list from the AppendRelInfos that you mention we now [1] build.
>
> [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=30833ba154
Looking at that commit again, AppendRelInfos are still not
On 2017/09/04 21:32, Ashutosh Bapat wrote:
> On Mon, Sep 4, 2017 at 10:04 AM, Amit Langote wrote:
>> By the way, if you want to get rid of PartitionedChildRelInfo, you can do
>> that as long as you find some other way of putting together the
>> partitioned_rels list to add
On 2017/09/04 20:46, Konstantin Knizhnik wrote:
> On 04.09.2017 12:59, Amit Langote wrote:
>> On 2017/09/04 18:19, Konstantin Knizhnik wrote:
>>> Concerning your suggestion to merge check_index_predicates() and
>>> remove_restrictions_implied_by_constraints() functions
Hi Konstantin,
On 2017/09/04 18:19, Konstantin Knizhnik wrote:
> On 04.09.2017 05:38, Amit Langote wrote:
>> On 2017/09/02 12:44, Thomas Munro wrote:
>>> On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik
>>> wrote:
>>>> postgres=# explain select * fr
Hi Ashutosh,
On 2017/09/04 13:51, Ashutosh Bapat wrote:
> Hi,
> Thomas's application to track patches told me that this patch needs
> rebase. It also required some changes to the code. Here's the updated
> version. I have squashed those two patches together.
Thanks for the rebased patch.
Would i
On 2017/09/04 12:38, Etsuro Fujita wrote:
> On 2017/09/02 4:10, Ashutosh Bapat wrote:
>> This rebase mainly changes patch 0001, which translates partition
>> hierarchy into inheritance hierarchy creating AppendRelInfos and
>> RelOptInfos for partitioned partitions. Because of that, it's not
>> nece
On 2017/09/02 12:44, Thomas Munro wrote:
> On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik
> wrote:
>> postgres=# explain select * from bt where k between 1 and 2 and v = 100;
>> QUERY PLAN
>> --
Thanks for the comments.
On 2017/09/02 2:52, Robert Haas wrote:
> On Thu, Aug 31, 2017 at 2:02 AM, Amit Langote
> wrote:
>> Attached is now also the set of patches that implement the actual
>> partition-pruning logic, viz. the last 3 patches (0004, 0005, and 0006) of
>&g
Hi Amit,
On 2017/09/03 16:07, Amit Khandekar wrote:
> 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
On 2017/08/31 4:45, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 12:47 PM, Ashutosh Bapat
> wrote:
>> +1. I think we should just pull out the OIDs from partition descriptor.
>
> Like this? The first patch refactors the expansion of a single child
> out into a separate function, and the second pa
Hi Ashutosh,
Thanks for the comments and sorry that it took me a while to reply here.
On 2017/08/23 20:16, Ashutosh Bapat wrote:
> On Mon, Aug 21, 2017 at 12:07 PM, Amit Langote
> wrote:
>> I've been working on implementing a way to perform plan-time
>> partition-pr
On 2017/08/30 12:03, Robert Haas wrote:
> On Tue, Aug 29, 2017 at 10:36 PM, Amit Langote
> wrote:
>>> I keep having the feeling that this is a big patch with a small patch
>>> struggling to get out. Is it really necessary to change
>>> RelationGetPartitionDispa
On 2017/08/29 4:26, Robert Haas wrote:
> I think this patch could be further simplified by continuing to use
> the existing function signature for RelationGetPartitionDispatchInfo
> instead of changing it to return a List * rather than an array. I
> don't see any benefit to such a change. The cur
On 2017/08/29 20:18, Etsuro Fujita wrote:
> On 2017/08/25 22:26, Robert Haas wrote:
>> On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita
>> wrote:
>>> Agreed, but I'd vote for fixing this in v10 as proposed; I agree that just
>>> ripping the CheckValidResultRel checks out entirely is not a good idea,
On 2017/08/26 3:28, Robert Haas wrote:
> On Mon, Aug 21, 2017 at 2:10 AM, Amit Langote
> wrote:
>> [ new patches ]
>
> I am failing to understand the point of separating PartitionDispatch
> into PartitionDispatch and PartitionTableInfo. That seems like an
> unnec
On 2017/08/22 1:08, Robert Haas wrote:
> On Mon, Aug 21, 2017 at 7:45 AM, Etsuro Fujita
> wrote:
>> If there are no objections, I'll add this to the open item list for v10.
>
> This seems fairly ad-hoc to me. I mean, now you have
> CheckValidResultRel not being called in just this one case -- bu
On 2017/08/22 9:39, Michael Paquier wrote:
> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote
> wrote:
>> On 2017/06/27 10:22, Michael Paquier wrote:
>>> On Mon, Jun 26, 2017 at 4:11 PM, Masahiko Sawada
>>> wrote:
>>>> Thank you for the patches!
On 2017/08/21 13:11, Ashutosh Bapat wrote:
> On Sat, Aug 19, 2017 at 1:21 AM, Robert Haas wrote:
>> On Fri, Aug 18, 2017 at 1:17 AM, Ashutosh Bapat
>> wrote:
>>> 0004 patch in partition-wise join patchset has code to expand
>>> partition hierarchy. That patch is expanding inheritance hierarchy in
I've been working on implementing a way to perform plan-time
partition-pruning that is hopefully faster than the current method of
using constraint exclusion to prune each of the potentially many
partitions one-by-one. It's not fully cooked yet though.
Meanwhile, I thought I'd share a couple of p
Hi Amit,
On 2017/08/17 21:18, Amit Khandekar wrote:
> Anyways, some more comments :
>
> In ExecSetupPartitionTupleRouting(), not sure why ptrinfos array is an
> array of pointers. Why can't it be an array of
> PartitionTupleRoutingInfo structure rather than pointer to that
> structure ?
AFAIK,
On 2017/08/19 2:09, Robert Haas wrote:
> On Fri, Aug 18, 2017 at 1:15 AM, Noah Misch wrote:
>> The above-described topic is currently a PostgreSQL 10 open item. Robert,
>> since you committed the patch believed to have created it, you own this open
>> item. If some other commit is more relevant
On 2017/08/18 4:54, Robert Haas wrote:
> On Thu, Aug 17, 2017 at 8:39 AM, Ashutosh Bapat
> wrote:
>> [2] had a patch with some changes to the original patch you posted. I
>> didn't describe those changes in my mail, since they rearranged the
>> comments. Those changes are not part of this patch an
Hi Ashutosh,
On 2017/08/17 21:39, Ashutosh Bapat wrote:
> On Thu, Aug 17, 2017 at 12:59 PM, Amit Langote
> wrote:
>>
>> Attached rest of the patches. 0001 has changes per Ashutosh's review
>> comments [2]:
>>
>> 0001: Relieve RelationGetPartitionDispatc
On 2017/08/17 10:09, Amit Langote wrote:
> On 2017/08/16 20:30, Amit Khandekar wrote:
>> On 16 August 2017 at 11:06, Amit Langote
>> wrote:
>> I am not
>> sure whether we are planning to commit these two things together or
>> incrementally :
>> 1. Expand
On 2017/08/17 13:56, Ashutosh Bapat wrote:
> On Thu, Aug 17, 2017 at 8:06 AM, Amit Langote
> wrote:
>> On 2017/08/17 11:22, Robert Haas wrote:
>>> On Wed, Aug 16, 2017 at 10:12 PM, Amit Langote
>>> wrote:
>>>>> In the catalogs we are using full "
On 2017/08/17 11:22, Robert Haas wrote:
> On Wed, Aug 16, 2017 at 10:12 PM, Amit Langote
> wrote:
>>> In the catalogs we are using full "partitioned" e.g. pg_partitioned_table.
>>> May
>>> be we should name the column as "inhchildpartitione
Hi Ashutosh,
Thanks for the review and the updated patch.
On 2017/08/16 21:48, Ashutosh Bapat wrote:
> On Wed, Aug 16, 2017 at 11:06 AM, Amit Langote
> wrote:
>
>>
>>> This patch series is blocking a bunch of other things, so it would be
>>> nice if you coul
Hi Amit,
Thanks for the comments.
On 2017/08/16 20:30, Amit Khandekar wrote:
> On 16 August 2017 at 11:06, Amit Langote
> wrote:
>
>> Attached updated patches.
>
> Thanks Amit for the patches.
>
> I too agree with the overall approach taken for keeping the locki
Fujita-san,
Thanks for reporting the bugs and patches to fix the same.
On 2017/08/15 21:20, Etsuro Fujita wrote:
> Hi hackers,
>
> I noticed that runtime stats for BEFORE ROW INSERT triggers on leaf
> partitions of partitioned tables aren't reported in EXPLAIN ANALYZE. Here
> is an example:
>
>
Thanks for the review.
On 2017/08/16 2:27, Robert Haas wrote:
> On Wed, Aug 9, 2017 at 10:11 PM, Amit Langote
> wrote:
>>> P.S. While I haven't reviewed 0002 in detail, I think the concept of
>>> minimizing what needs to be built in RelationGetPartitionDispatc
On 2017/08/10 18:52, Beena Emerson wrote:
> Hi Amit,
>
> On Thu, Aug 10, 2017 at 7:41 AM, Amit Langote
> wrote:
>> On 2017/08/05 2:25, Robert Haas wrote:
>>> Concretely, my proposal is:
>>>
>>> P.S. While I haven't reviewed 0002 in detail, I th
(Sorry Robert for the duplicate message, I mistakenly didn't hit Reply All)
On Fri, Aug 11, 2017 at 2:54 Robert Haas wrote:
> On Wed, Aug 9, 2017 at 10:14 PM, Amit Langote
> wrote:
> >> That seems like overkill. I'm good with "greater than or equal to".
On 2017/08/10 5:59, Tom Lane wrote:
> Alvaro Herrera writes:
>> Dean Rasheed wrote:
>>> There was an earlier suggestion to use "greater than or equal to". I
>>> think that would work quite well:
>
>> Is it possible to detect the equality case specifically and use a
>> different errdetail? Someth
On 2017/08/05 2:25, Robert Haas wrote:
> Concretely, my proposal is:
>
> 1. Before calling RelationGetPartitionDispatchInfo, the calling code
> should use find_all_inheritors to lock all the relevant relations (or
> the planner could use find_all_inheritors to get a list of relation
> OIDs, store
On 2017/08/09 13:03, David G. Johnston wrote:
> On Tue, Aug 8, 2017 at 8:34 PM, Tom Lane wrote:
>
>> A small suggestion is that it'd be better to write it like "Specified
>> upper bound \"%s\" precedes lower bound \"%s\"." I think "succeeds" has
>> more alternate meanings than "precedes", so the
On 2017/08/09 9:03, David G. Johnston wrote:
> On Tue, Aug 8, 2017 at 4:33 PM, Dean Rasheed wrote:
>> Well perhaps verbosity-reduction isn't sufficient justification but I
>> still think this is correct because logically any values in the bound
>> after MINVALUE/MAXVALUE are irrelevant, so it seems
On 2017/08/09 3:50, Robert Haas wrote:
> In the original table partitioning commit
> (f0e44751d7175fa3394da2c8f85e3ceb3cdbfe630), we introduced the
> following code, which hasn't changed materially since then:
>
> +if (partition_rbound_cmp(key, lower->datums,
> lower->content, true
On 2017/08/08 4:34, Robert Haas wrote:
> On Mon, Aug 7, 2017 at 2:54 AM, Amit Langote
> wrote:
>> As long as find_all_inheritors() is a place only to determine the order in
>> which partitions will be locked, it's fine. My concern is about the time
>> of actual
On 2017/08/07 14:37, Amit Khandekar wrote:
> On 4 August 2017 at 22:55, Robert Haas wrote:
>> P.S. While I haven't reviewed 0002 in detail, I think the concept of
>> minimizing what needs to be built in RelationGetPartitionDispatchInfo
>> is a very good idea.
>
> True. I also think, RelationGetPa
On 2017/08/05 2:25, Robert Haas wrote:
> On Fri, Aug 4, 2017 at 3:38 AM, Amit Langote
> wrote:
>> The current way to expand inherited tables, including partitioned tables,
>> is to use either find_all_inheritors() or find_inheritance_children()
>> depending on the con
On 2017/08/07 15:22, Etsuro Fujita wrote:
> On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too.
> Although, looking at the following hunk:
>>
>> + Assert(partrel->rd_rel->relkind == RELKIND_RELATION ||
>> +partrel->rd_r
On 2017/08/04 20:28, Ashutosh Bapat wrote:
> On Fri, Aug 4, 2017 at 1:08 PM, Amit Langote
> wrote:
>> The current way to expand inherited tables, including partitioned tables,
>> is to use either find_all_inheritors() or find_inheritance_children()
>> depending on the con
Fujita-san,
On 2017/08/07 12:45, Etsuro Fujita wrote:
> Hi,
>
> I noticed that tuple-routing for partitioned tables that contain
> non-writable foreign partitions doesn't work as expected. Here is an
> example:
>
> postgres=# create extension file_fdw;
> postgres=# create server file_server for
On 2017/08/04 18:11, Ashutosh Bapat wrote:
> After that commit in session 1, we get an Append plan
> postgres=# explain verbose select * from parent;
> QUERY PLAN
> ---
> Append (cost=0.00..0.00 rows=1 wid
Hi Thomas,
On 2017/08/07 10:58, Thomas Munro wrote:
> Hi hackers,
>
> If you drop a column from a partitioned table then it has a TupleDesc
> that matches existing partitions, but new partitions created after
> that have non-same TupleDescs (according to convert_tuples_by_name)
> because they don
On 2017/08/05 11:05, Robert Haas wrote:
> On Thu, Aug 3, 2017 at 8:45 PM, Amit Langote
> wrote:
>>> 0003 needs a rebase.
>>
>> Rebased patch attached.
>
> Committed.
Thank you.
> I think 0004 is a new feature, so I'm leaving that for v11.
Sure.
By t
On 2017/08/02 19:49, Amit Khandekar wrote:
> On 2 August 2017 at 14:38, Amit Langote wrote:
>>> One approach I had considered was to have find_inheritance_children()
>>> itself lock the children in bound order, so that everyone will have
>>> bound-ordered oids, b
The current way to expand inherited tables, including partitioned tables,
is to use either find_all_inheritors() or find_inheritance_children()
depending on the context. They return child table OIDs in the (ascending)
order of those OIDs, which means the callers that need to lock the child
tables
On 2017/08/04 1:08, David G. Johnston wrote:
> On Thu, Aug 3, 2017 at 8:53 AM, Tom Lane wrote:
>
>> Robert Haas writes:
>>> So maybe --load-via-partition-root if nobody likes my previous
>>> suggestion of --partition-data-via-root ?
>>
>> WFM.
>>
>
> +1
+1.
Thanks,
Amit
--
Sent via pgsql
On 2017/08/04 2:13, Robert Haas wrote:
> On Thu, Aug 3, 2017 at 12:35 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Aug 2, 2017 at 9:41 PM, Amit Langote
>>> wrote:
>>>> Attached is a patch. I think this could be considered a bug-fix,
>>
On 2017/08/04 1:06, Robert Haas wrote:
> On Thu, Aug 3, 2017 at 4:40 AM, Etsuro Fujita
> wrote:
>> On 2017/08/03 17:12, Amit Langote wrote:
>>> Attached updated patches.
>>
>> Thanks for the patch! That looks good to me.
>
> Committed with some comment
On 2017/08/04 3:29, Robert Haas wrote:
> On Thu, Aug 3, 2017 at 1:04 AM, Amit Langote
> wrote:
>> Alright, attached updated 0001 does that.
>
> Committed 0001 and 0002.
Thanks.
> 0003 needs a rebase.
Rebased patch attached.
Thanks,
Amit
From f069845c027acc36aab4790d6d6
Fujita-san,
Thanks for the review.
On 2017/08/03 16:01, Etsuro Fujita wrote:
> On 2017/08/02 15:21, Amit Langote wrote:
>> On 2017/08/02 1:33, Amit Khandekar wrote:
>>> ---
>>>
>>> Few more comments :
>>>
>>> @@ -1240,7 +1247,
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:
>>> Instead of callers of map_partition_varattnos() reporting error, we
>>> can have map_partition_vara
On 2017/08/02 20:35, Robert Haas wrote:
> On Tue, Aug 1, 2017 at 9:44 PM, Amit Langote
> wrote:
>> I too dislike the shape of attachRel. How about we rename attachRel to
>> attachrel? So, attachrel_children, attachrel_constr, etc. It's still
>> long though... :)
Thanks Jeevan for looking at this. See comments below.
On 2017/08/02 19:04, Jeevan Ladhe wrote:
> On Wed, Aug 2, 2017 at 10:26 AM, Amit Langote wrote:
>> The patch's job is simple:
>>
>> - Remove the check in the parser that causes an error the moment the
>&g
On 2017/08/02 20:40, Robert Haas wrote:
> On Wed, Aug 2, 2017 at 3:46 AM, Ashutosh Bapat
> wrote:
>> If the user has specified "not valid" for a constraint on the foreign
>> table, there is high chance that s/he is aware of the fact that the
>> remote table that the foreign table points to has som
On 2017/07/29 2:45, Amit Khandekar wrote:
> On 28 July 2017 at 20:10, Robert Haas wrote:
>> On Wed, Jul 26, 2017 at 2:13 AM, Amit Langote wrote:
>>> I checked that we get the same result relation order with both the
>>> patches, but I would like to highlight a nota
On 2017/08/02 15:21, Amit Langote wrote:
> Thanks Fuita-san and Amit for reviewing.
Sorry, I meant Fujita-san.
- 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 Fuita-san and Amit for reviewing.
On 2017/08/02 1:33, Amit Khandekar wrote:
> On 1 August 2017 at 15:11, Etsuro Fujita wrote:
>> On 2017/07/31 18:56, Amit Langote wrote:
>>> Yes, that's what's needed here. So we need to teach
>>> map_variable_attno
Starting a new thread for a patch I posted earlier [1] to handle ON
CONFLICT DO NOTHING when inserting into a partitioned table. It's
intended for PG 11 and so registered in the upcoming CF.
Summary of the previous discussion and the patch for anyone interested:
Currently, if an INSERT statement
On 2017/08/02 9:31, Amit Langote wrote:
> On 2017/08/02 4:02, Robert Haas wrote:
>> On Tue, Aug 1, 2017 at 12:26 AM, Amit Langote
>> wrote:
>>> So is the latest patch posted upthread to process ON CONFLICT DO NOTHING
>>> using locally-defined unique indexe
On 2017/08/02 10:27, Robert Haas wrote:
> On Tue, Aug 1, 2017 at 9:23 PM, Amit Langote
> wrote:
>> Since ATExecAttachPartition() deals with the possibility that the table
>> being attached itself might be partitioned, someone reading the code might
>> find it helpful to g
Thanks for reviewing.
On 2017/08/02 2:54, Robert Haas wrote:
> On Mon, Jul 31, 2017 at 11:10 PM, Amit Langote
> wrote:
>> OK, these cosmetic changes are now in attached patch 0001.
>
> Regarding 0001:
>
> -List *childrels;
> +List *attachRel_child
On 2017/08/02 4:02, Robert Haas wrote:
> On Tue, Aug 1, 2017 at 12:26 AM, Amit Langote
> wrote:
>> So is the latest patch posted upthread to process ON CONFLICT DO NOTHING
>> using locally-defined unique indexes on leaf partitions something to
>> consider?
>
> Yeah
On 2017/08/01 17:54, Simon Riggs wrote:
> On 1 August 2017 at 08:37, Amit Langote wrote:
>> On 2017/08/01 15:22, Simon Riggs wrote:
>>> On 1 August 2017 at 07:16, Amit Langote
>>> wrote:
>>>> In f27a6b15e656 (9.6 & later), we decided to "Mark CH
On 2017/08/01 15:22, Simon Riggs wrote:
> On 1 August 2017 at 07:16, Amit Langote wrote:
>> In f27a6b15e656 (9.6 & later), we decided to "Mark CHECK constraints
>> declared NOT VALID valid if created with table." In retrospect,
>> constraints on foreign ta
On 2017/08/01 11:44, David G. Johnston wrote:
> On Mon, Jul 31, 2017 at 7:06 PM, Robert Haas wrote:
>
>> On Thu, Jul 13, 2017 at 8:40 PM, Amit Langote
>> wrote:
>>> On 2017/07/13 19:57, Ashutosh Bapat wrote:
>>>> On Thu, Jul 13, 2017 at 12:01 PM, Amit Lan
In f27a6b15e656 (9.6 & later), we decided to "Mark CHECK constraints
declared NOT VALID valid if created with table." In retrospect,
constraints on foreign tables should have been excluded from consideration
in that commit, because the thinking behind the aforementioned commit
(that the constraint
On 2017/08/01 12:45, Etsuro Fujita wrote:
> On 2017/08/01 10:18, Amit Langote wrote:
>> Good points; fixed in the updated patch.
>
> I should have mentioned this in an earlier mail, but one thing I noticed
> is this:
>
> -the remote server.
> +the remote serve
On 2017/08/01 10:52, Robert Haas wrote:
> On Mon, Apr 3, 2017 at 6:28 AM, Amit Langote
> wrote:
>> Since nowhere has the user asked to ensure unique(b) across partitions by
>> defining the same on parent, this seems just fine. But one question to
>> ask may be whether t
Thanks for taking a look at this.
On 2017/08/01 6:26, Robert Haas wrote:
> On Wed, Jul 26, 2017 at 9:50 PM, Amit Langote
> wrote:
>> At least patch 0001 does address a bug. Not sure if we can say that 0002
>> addresses a bug; it implements a feature that might be a
>&g
On 2017/08/01 10:10, David G. Johnston wrote:
> On Mon, Jul 31, 2017 at 5:42 PM, Amit Langote > wrote:
>
>>
>> On a second thought though, I think we should list the foreign table
>> partitions' limitations in only one place, that is, the CREATE FOREIGN
>&g
On 2017/08/01 6:41, David G. Johnston wrote:
> On Tue, Jul 25, 2017 at 11:29 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp> wrote:
>
>>> I'm curious what the other limitations are...
>>
>> When I first wrote that documentation line (I am assuming yo
Thanks a lot Amit for looking at this and providing some useful pointers.
On 2017/07/28 20:46, Amit Khandekar wrote:
> On 28 July 2017 at 11:17, Amit Langote wrote:
>> On 2017/07/26 16:58, Amit Langote wrote:
>>> Rajkumar Raghuwanshi reported [1] on the "UPDATE partiti
Thank you for weighing in and reviewing the patch.
On 2017/07/28 20:55, Etsuro Fujita wrote:
> On 2017/07/26 15:29, Amit Langote wrote:
>> On 2017/07/25 9:43, David G. Johnston wrote:
>>> On Mon, Jul 24, 2017 at 5:19 PM, Amit Langote wrote:
>>> I'm curious what the
On 2017/07/26 16:58, Amit Langote wrote:
> Rajkumar Raghuwanshi reported [1] on the "UPDATE partition key" thread
> that whole-row vars don't play nicely with partitioned table operations.
>
> For example, when used to convert WITH CHECK OPTION constraint expressions
Thanks for looking at this again.
On 2017/07/26 23:31, Ashutosh Bapat wrote:
> On Wed, Jul 12, 2017 at 7:17 AM, Amit Langote
> wrote:
>>
>> Thanks for the review. Patch updated taking care of the comments.
>
> The patches still apply and compile. make check runs w
On 2017/07/25 21:55, Rajkumar Raghuwanshi wrote:
> Got one more observation : update... returning is not working with whole
> row reference. please take a look.
>
> postgres=# create table part (a int, b int) partition by range(a);
> CREATE TABLE
> postgres=# create table part_p1 partition of par
Rajkumar Raghuwanshi reported [1] on the "UPDATE partition key" thread
that whole-row vars don't play nicely with partitioned table operations.
For example, when used to convert WITH CHECK OPTION constraint expressions
and RETURNING target list expressions, it will error out if the
expressions con
On 2017/07/25 9:43, David G. Johnston wrote:
> On Mon, Jul 24, 2017 at 5:19 PM, Amit Langote > wrote:
>
>> On 2017/07/25 6:28, mtun...@gmail.com wrote:
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 14759
>>>
On 2017/07/26 6:07, Robert Haas wrote:
> On Thu, Jul 13, 2017 at 1:09 PM, Amit Khandekar
> 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 2017/07/24 17:30, Etsuro Fujita wrote:
> On 2017/07/24 16:16, Amit Khandekar wrote:
>> On 24 July 2017 at 12:11, Amit Langote
>> wrote:
>>> Attached is the updated version of your patch.
>
> Good catch, Amit K. and Amit L.!
>
>> Now that this is done,
101 - 200 of 1334 matches
Mail list logo
