Fujita-san,
On 2017/06/21 16:59, Etsuro Fujita wrote:
> Commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50 added this to
> ExecInitModifyTable:
>
> + /* The root table RT index is at the head of the partitioned_rels list */
> + if (node->partitioned_rels)
> + {
> + Index root_rti;
> +
On 2017/06/21 3:53, Robert Haas wrote:
> On Tue, Jun 20, 2017 at 2:54 AM, Amit Khandekar
> wrote:
>>> I guess I don't see why it should work like this. In the INSERT case,
>>> we must build withCheckOption objects for each partition because those
>>> partitions don't appear in the plan otherwise
On 2017/06/21 18:49, Dean Rasheed wrote:
> On 20 June 2017 at 03:01, Amit Langote wrote:
>> Hmm, yes. The following exercise convinced me.
>>
>> create table r (a int) partition by range (a);
>> create table r1 partition of r for values from (1) to (10);
>> crea
On 2017/06/21 21:37, Jeevan Ladhe wrote:
> Hi Amit,
>
> On Thu, Jun 15, 2017 at 12:31 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp> wrote:
>
>> Oops, I meant to send one more comment.
>>
>> On 2017/06/15 15:48, Amit Langote wrote:
&
On 2017/06/22 10:01, Michael Paquier wrote:
> #3 implies that the index AM logic is implemented in the table
> AM. Not saying that it is not useful, but it does not feel natural to
> have the planner request for a sequential scan, just to have the table
> AM secretly do some kind of index/skipping
On 2017/06/22 11:25, Etsuro Fujita wrote:
> On 2017/06/21 23:52, Robert Haas wrote:
>
>> You're right that there is a comment missing from the function header,
>> but it's not too hard to figure out what it should be. Just consult
>> the definition of ModifyTable itself:
>>
>> /* RT inde
On 2017/06/22 12:26, Peter Eisentraut wrote:
> On 6/14/17 01:34, Amit Langote wrote:
>> How about the attached patch that teaches pgrowlocks() to error out unless
>> a meaningful result can be returned? With the patch, it will issue a "%s
>> is not a table" message
Attached a patch for $SUBJECT.
- * If RecPtr is not NULL, try to read a record at that position. Otherwise
+ * If RecPtr is valid, try to read a record at that position. Otherwise
Commit 4d6d425ab8d addressed the comment above XLogReadRecord() in
xlogreader.c, but missed the same above ReadReco
On 2017/06/22 16:56, Michael Paquier wrote:
> On Wed, Jun 21, 2017 at 9:42 AM, Amit Langote
> wrote:
>> On 2017/06/20 20:37, Amit Kapila wrote:
>>> On Tue, Jun 20, 2017 at 1:50 PM, Amit Langote
>>> wrote:
>>>> On 2017/06/19 23:31, Tom Lane wrote:
>
On 2017/06/23 0:00, Robert Haas wrote:
> On Fri, May 19, 2017 at 3:46 AM, Amit Langote
> wrote:
>> In match_eclasses_to_foreign_key_col(), there is this:
>>
>> if (em->em_is_child)
>> continue; /* ignore children here *
On 2017/06/23 5:44, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Attached a patch for $SUBJECT.
>>
>> - * If RecPtr is not NULL, try to read a record at that position. Otherwise
>> + * If RecPtr is valid, try to read a record at that position. Otherwise
>>
&g
On 2017/06/22 20:48, amul sul wrote:
> Hi,
>
> While working on the another patch, I came across the case where
> I need an auto generated partition for a mutil-column range partitioned
> table having following range bound:
>
> PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10)
> PARTITION p2
On 2017/06/23 10:22, Masahiko Sawada wrote:
> On Thu, Jun 22, 2017 at 6:55 PM, Amit Langote
> wrote:
>> On 2017/06/22 16:56, Michael Paquier wrote:
>>> Did you check this patch with wal_consistency_checking? I am getting
>>> failures so your patch does not
On 2017/06/23 13:42, amul sul wrote:
> On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote wrote:
>> On 2017/06/22 20:48, amul sul wrote:
>>> This happened because of UNBOUNDED handling, where it is a negative infinite
>>> if it is in FROM clause. Wondering can't w
On 2017/06/23 15:07, Michael Paquier wrote:
> On Fri, Jun 23, 2017 at 2:56 PM, Masahiko Sawada
> wrote:
>> Thank you for updating the patch. It looks good to me.
>> BTW I'm inclined to have a regression test case where doing 'make
>> check' to the streaming replication environment with
>> wal_con
Thanks for the review again.
On 2017/06/22 19:55, Ashutosh Bapat wrote:
> On Thu, Jun 15, 2017 at 4:06 PM, Amit Langote
> wrote:
>>
>> Anyway, I tried to implement the refactoring in patch 0002, which is not
>> all of the patch 0001 that Jeevan posted. Please take a lo
On 2017/06/24 5:04, Tom Lane wrote:
> Peter Eisentraut writes:
>> We also allow the same column more than once in an index. We probably
>> don't have to be more strict here.
>
> There actually are valid uses for the same column more than once in
> an index, eg if you use a different operator cla
On 2017/06/26 10:54, Michael Paquier wrote:
> On Fri, Jun 23, 2017 at 11:17 AM, Amit Langote
> wrote:
>> That was it, thanks for the pointer.
>
> GinInitMetabuffer() sets up pd_lower and pd_upper anyway using
> PageInit so the check of PageIsVerified is guaranteed to work in
Hello,
On 2017/06/26 17:46, Kyotaro HORIGUCHI wrote:
> Hello.
>
> I had a case of unexpected error caused by ALTER TABLE NO
> INHERIT.
>
> =# CREATE TABLE p (a int);
> =# CREATE TABLE c1 () INHERITS (p);
>
> session A=# BEGIN;
> session A=# ALTER TABLE c1 NO INHERIT p;
>
> session B=# EXPLAIN
On 2017/06/26 18:44, Kyotaro HORIGUCHI wrote:
> At Mon, 26 Jun 2017 18:16:42 +0900, Amit Langote wrote:
>>
>> I recall I had proposed a fix for the same thing some time ago [1].
>
> Wow. About 1.5 years ago and stuck? I have a concrete case where
> this harms so I'
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! I checked additional patches for brin and
>> spgist. They look good to me.
>
> Last versions are still missing something: brin_mask() and spg_mask()
> can be upda
Attached fixes $SUBJECT.
s/fetch_ckpt/fetching_ckpt/g
Thanks,
Amit
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index 0a6314a642..5b6cec8dee 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -4221,10 +4221,10 @@ ReadRe
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 was made yesterday:
commit 501ed02cf6f4f60c3357775eb07578aebc912d3a
Author: Andrew Gierth
Date: Wed Jun 28 18:55:03 2017 +0100
Fix trans
Hi,
On 2017/06/29 13:45, Kyotaro HORIGUCHI wrote:
> Thank you for looking this.
>
> At Wed, 28 Jun 2017 10:23:54 +0200, Antonin Houska wrote:
>> Kyotaro HORIGUCHI wrote:
>>
>>> The patch got conflicted. This is a new version just rebased to
>>> the current master. Furtuer amendment will be taken
On 2017/06/23 17:00, Dean Rasheed wrote:
> On 23 June 2017 at 08:01, Ashutosh Bapat
> wrote:
>> The way we have designed our syntax, we don't have a way to tell that
>> p3 comes after p2 and they have no gap between those. But I don't
>> think that's your question. What you are struggling with is
On 2017/07/01 3:49, Peter Eisentraut wrote:
> On 6/27/17 20:54, Amit Langote wrote:
>> Attached fixes $SUBJECT.
>>
>> s/fetch_ckpt/fetching_ckpt/g
>
> committed
Thanks.
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Hi Dean,
Thanks a lot for the review.
On 2017/07/03 1:59, Dean Rasheed wrote:
> On 30 June 2017 at 09:06, Amit Langote wrote:
>> When testing the patch, I realized that the current code in
>> check_new_partition_bound() that checks for range partition overlap had a
>> lat
On 2017/07/03 2:15, Dean Rasheed wrote:
> On 30 June 2017 at 10:04, Ashutosh Bapat
> wrote:
>> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote
>> wrote:
>>>
>>> Alright, I spent some time implementing a patch to allow specifying
>>> -infinity an
On 2017/07/03 14:00, Amit Langote wrote:
> On 2017/07/03 2:15, Dean Rasheed wrote:
>> On 30 June 2017 at 10:04, Ashutosh Bapat
>> wrote:
>>> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote
>>> wrote:
>>>>
>>>> Alright, I spent some time im
Hi Dean,
On 2017/07/03 17:36, Dean Rasheed wrote:
> On 3 July 2017 at 06:00, Amit Langote wrote:
>> On 2017/07/03 2:15, Dean Rasheed wrote:
>>> My first thought was UNBOUNDED ABOVE/BELOW, because that matches the
>>> terminology already in use of upper and lower boun
On 2017/07/02 20:10, Robert Haas wrote:
> On Fri, Jun 30, 2017 at 4:20 PM, Robert Haas wrote:
>> I don't think the approach of building a hash table to figure out
>> which result rels have already been created is a good one. That too
>> feels like something that the planner should be figuring out
Thanks for the review.
On 2017/07/03 20:13, Ashutosh Bapat wrote:
> Thanks for working on the previous comments. The code really looks good now.
> On Fri, Jun 23, 2017 at 2:29 PM, Amit Langote
> wrote:
>>
>>> Don't we need an exclusive lock to
>>> make sur
On 2017/07/04 17:25, Etsuro Fujita wrote:
> On 2017/07/03 18:54, Amit Langote wrote:
>> On 2017/07/02 20:10, Robert Haas wrote:
>>> That
>>> seems pretty easy to do - just have expand_inherited_rtentry() notice
>>> that it's got a partitioned table and
On 2017/07/04 17:55, Etsuro Fujita wrote:
> This comment in an error handling in ExecPartitionCheck():
>
> if (!ExecCheck(resultRelInfo->ri_PartitionCheckExpr, econtext))
> {
> char *val_desc;
> Relationorig_rel = rel;
>
> /* See the comment above. */
>
Fujita-san,
On 2017/06/29 20:20, Etsuro Fujita wrote:
> Hi,
>
> Here is a patch for $subject. This is based on Amit's original patch
> (patch '0007-Tuple-routing-for-partitioned-tables-15.patch' in [1]).
Thanks a lot for taking this up.
> Main changes are:
>
> * I like Amit's idea that for ea
Hi Dean,
On 2017/07/04 16:49, Dean Rasheed wrote:
> On 3 July 2017 at 10:32, Amit Langote wrote:
>> On 2017/07/03 17:36, Dean Rasheed wrote:
>>> The bigger question is do we want this for PG10? If so, time is
>>> getting tight. My feeling is that we do, because otherwi
Hi Dean,
On 2017/07/05 23:18, Dean Rasheed wrote:
> On 5 July 2017 at 10:43, Amit Langote wrote:
>> In retrospect, that sounds like something that was implemented in the
>> earlier versions of the patch, whereby there was no ability to specify
>> UNBOUNDED on a per-column
On 2017/07/06 18:30, Dean Rasheed wrote:
> On 5 July 2017 at 10:43, Amit Langote wrote:
>> 0001 is your patch to tidy up check_new_partition_bound() (must be
>> applied before 0002)
>>
>
> I pushed this first patch, simplifying check_new_partition_bound() for
> ran
Hi Mark,
On 2017/07/07 9:02, Mark Kirkwood wrote:
> I've been trying out the new partitioning in version 10. Firstly, I must
> say this is excellent - so much nicer than the old inheritance based method!
Thanks. :)
> My only niggle is the display of partitioned tables via \d etc. e.g:
>
> part=#
On 2017/07/07 4:55, Dean Rasheed wrote:
> On 5 July 2017 at 18:07, Dean Rasheed wrote:
>> So if we were to go for maximum flexibility and compatibility with
>> Oracle, then perhaps what we would do is more like the original idea
>> of UNBOUNDED ABOVE/BELOW, except call them MINVALUE and MAXVALUE,
Fujita-san,
On 2017/07/06 16:06, Etsuro Fujita wrote:
> Here is an example:
>
> postgres=# create table col_desc (a int, b int) partition by list (a);
> postgres=# create table col_desc_1 partition of col_desc for values in (1);
> postgres=# alter table col_desc_1 add check (b > 0);
> postgres=#
On 2017/07/08 14:12, Mark Kirkwood wrote:
> On 07/07/17 19:54, Michael Banck wrote:
>> On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote:
>>> On 07/07/17 13:29, Amit Langote wrote:
>>>> Someone complained about this awhile back [1]. And then it came
Fujita-san,
On 2017/07/10 14:15, Etsuro Fujita wrote:
> On 2017/07/07 18:47, Amit Langote wrote:
>> On 2017/07/06 16:06, Etsuro Fujita wrote:
>>> I think this should be fixed. Attached is a patch for that.
>
>> How about setting ri_RangeTableIndex of the partition Re
On 2017/07/10 15:32, Craig Ringer wrote:
> On 8 July 2017 at 00:03, David Fetter wrote:
>
>> On Fri, Jul 07, 2017 at 10:29:26AM +0900, Amit Langote wrote:
>>> Hi Mark,
>>>
>>> On 2017/07/07 9:02, Mark Kirkwood wrote:
>>>> I've been t
On 2017/07/11 7:33, Robert Haas wrote:
> On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote
> wrote:
>> Actually, if \d had shown RELKIND_PARTITIONED_TABLE tables as of Type
>> "partitioned table", we wouldn't need a separate flag for marking a table
>> as
On 2017/07/11 10:34, Paul A Jungwirth wrote:
>> Also, there seems to be at least some preference
>> for excluding partitions by default from the \d listing.
>
> As another user of partitions I'll chime in and say that would be very
> nice! On the other hand, with pre-10 partitions you do see all t
On 2017/07/11 19:49, Ashutosh Bapat wrote:
> On Tue, Jul 4, 2017 at 9:51 AM, Amit Langote
> wrote:
>
>>
>> Attached updated patches.
>
> There's an extra "we" in
> +* Note that attachRel's OID is in this list. If it's partitio
On 2017/07/12 4:24, Dean Rasheed wrote:
> On 11 July 2017 at 13:29, Ashutosh Bapat
> wrote:
>> Most of the patch seems to be replacing "content" with "kind",
>> RangeDatumContent with PartitionRangeDatumKind and RANGE_DATUM_FINITE
>> with PARTITION_RANGE_DATUM_VALUE. But those changes in name do
On 2017/07/11 18:57, Ashutosh Bapat wrote:
> On Tue, Jul 11, 2017 at 4:16 AM, David Fetter wrote:
>> So whatever we land on needs to mention partition_of and
>> has_partitions. Is that latter just its immediate partitions?
>> Recursion all the way down? Somewhere in between?
>>
>
> We have patc
On 2017/07/11 13:34, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote
>> wrote:
>
>>> Actually, if \d had shown RELKIND_PARTITIONED_TABLE tables as of Type
>>> "partitioned table", we wouldn't nee
On 2017/07/12 12:47, Ashutosh Bapat wrote:
> On Wed, Jul 12, 2017 at 8:23 AM, Amit Langote
> wrote:
>> On 2017/07/11 18:57, Ashutosh Bapat wrote:
>>> On Tue, Jul 11, 2017 at 4:16 AM, David Fetter wrote:
>>>> So whatever we land on needs to mention partition_of
On 2017/07/12 13:09, Amit Langote wrote:
> On 2017/07/12 12:47, Ashutosh Bapat wrote:
>> Do you see that those patches can be used in current discussion in any way?
>
> It wouldn't really be a bad idea to put that patch here, because there's
> no special reason for
On 2017/07/12 23:58, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2017/07/11 13:34, Alvaro Herrera wrote:
>>> Robert Haas wrote:
>>>> On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote
>>>> wrote:
>>>
>>>>> Actually, if \d had sh
The description of \d[S+] currently does not mention that it will list
materialized views and foreign tables. Attached fixes that.
Thanks,
Amit
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index b3dbb5946e..66fd8b36f9 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -219,7
On 2017/07/13 7:23, Dean Rasheed wrote:
> On 12 July 2017 at 15:58, Alvaro Herrera wrote:
>> Amit Langote wrote:
>>> On 2017/07/11 13:34, Alvaro Herrera wrote:
>>>> However, the "list tables"
>>>> command \dt should definitely IMO not li
On 2017/07/13 19:57, Ashutosh Bapat wrote:
> On Thu, Jul 13, 2017 at 12:01 PM, Amit Langote
> wrote:
>> The description of \d[S+] currently does not mention that it will list
>> materialized views and foreign tables. Attached fixes that.
>>
>
> I guess the sa
On 2017/07/18 16:20, Etsuro Fujita wrote:
> On 2017/07/18 11:03, Robert Haas wrote:
>> On Mon, Jul 10, 2017 at 5:44 PM, Robert Haas wrote:
>>> The posted patches look OK to me. Barring developments, I will commit
>>> them on 2017-07-17, or send another update by then.
>>
>> Committed them.
>
> T
On 2017/07/20 15:05, Ashutosh Bapat wrote:
> On Wed, Jul 19, 2017 at 9:54 AM, Rafia Sabih
> wrote:
>>
>> Partition information:
>> Type of partitioning - single column range partition
>> Tables partitioned - Lineitem and orders
>>
>> Lineitem -
>> Partition key = l_orderkey
>> No of partitions = 1
On 2017/07/20 22:19, Tom Lane wrote:
> Greg Stark writes:
>> On 19 July 2017 at 00:26, Tom Lane wrote:
>>> It's probably a bit late in the v10 cycle to be taking any risks in
>>> this area, but I'd vote for ripping out RememberToFreeTupleDescAtEOX
>>> as soon as the v11 cycle opens, unless someon
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 ExecWithCheckOptions; it
>>> doesn't take any care for partition tables, so the column description in
>>> the error message for WCO_VIEW_CHECK is b
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,
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/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
>>>
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 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
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/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
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
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
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
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
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: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
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
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 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
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 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/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
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 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
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
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
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
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
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 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
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: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 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
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,
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
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 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: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
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/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
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
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/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
401 - 500 of 1334 matches
Mail list logo
