Re: [HACKERS] Declarative partitioning - another take

Hi Maksim, On 2017/04/07 19:52, Maksim Milyutin wrote: On 07.04.2017 13:05, Etsuro Fujita wrote: On 2016/12/09 19:46, Maksim Milyutin wrote: I would like to work on two tasks: - insert (and eventually update) tuple routing for foreign partition. - the ability to create an index on the

Re: [HACKERS] Declarative partitioning - another take

On Wed, May 10, 2017 at 6:50 AM, Etsuro Fujita wrote: > I started working on this. I agree that the changes made in > make_modifytable would be unacceptable, but I'd vote for Amit's idea of > passing a modified PlannerInfo to PlanForeignModify so that the FDW can do

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/18 1:43, Robert Haas wrote: On Thu, Nov 17, 2016 at 6:27 AM, Amit Langote wrote: - The code in make_modifytable() to swap out the rte_array for a fake one looks like an unacceptable kludge. I don't know offhand what a better design would look like,

Re: [HACKERS] Declarative partitioning - another take

On 2017/05/10 12:59, Robert Haas wrote: > On Tue, May 9, 2017 at 11:54 PM, Thomas Munro > wrote: >> +A statement that targets a parent table in a inheritance or partitioning >> >> A tiny typo: s/a inheritance/an inheritance/ > > Now he tells me. Thanks both.

Re: [HACKERS] Declarative partitioning - another take

On Tue, May 9, 2017 at 11:54 PM, Thomas Munro wrote: > +A statement that targets a parent table in a inheritance or partitioning > > A tiny typo: s/a inheritance/an inheritance/ Now he tells me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

Re: [HACKERS] Declarative partitioning - another take

On Wed, May 10, 2017 at 3:51 PM, Robert Haas wrote: > On Sun, May 7, 2017 at 9:44 PM, Amit Langote > wrote: >> I think that makes sense. Modified it to read: "A statement that targets >> a parent table in a inheritance or partitioning

Re: [HACKERS] Declarative partitioning - another take

On Sun, May 7, 2017 at 9:44 PM, Amit Langote wrote: > I think that makes sense. Modified it to read: "A statement that targets > a parent table in a inheritance or partitioning hierarchy..." in the > attached updated patch. LGTM. Committed. -- Robert Haas

Re: [HACKERS] Declarative partitioning - another take

On 2017/05/08 10:22, Thomas Munro wrote: > On Mon, May 8, 2017 at 12:47 PM, Amit Langote > wrote: >> On 2017/05/03 2:48, Robert Haas wrote: >>> On Tue, May 2, 2017 at 3:30 AM, Amit Langote >>> wrote: You're right. I agree that

Re: [HACKERS] Declarative partitioning - another take

On Mon, May 8, 2017 at 12:47 PM, Amit Langote wrote: > On 2017/05/03 2:48, Robert Haas wrote: >> On Tue, May 2, 2017 at 3:30 AM, Amit Langote >> wrote: >>> You're right. I agree that whatever text we add here should be pointing >>>

Re: [HACKERS] Declarative partitioning - another take

On 2017/05/03 2:48, Robert Haas wrote: > On Tue, May 2, 2017 at 3:30 AM, Amit Langote > wrote: >> You're right. I agree that whatever text we add here should be pointing >> out that statement-level triggers of affected child tables are not fired, >> when root

Re: [HACKERS] Declarative partitioning - another take

On Tue, May 2, 2017 at 3:30 AM, Amit Langote wrote: > You're right. I agree that whatever text we add here should be pointing > out that statement-level triggers of affected child tables are not fired, > when root parent is specified in the command. > > Since there

Re: [HACKERS] Declarative partitioning - another take

On 2017/05/01 21:30, Robert Haas wrote: > On Mon, May 1, 2017 at 12:18 AM, Amit Langote > wrote: >> Attached updated patch. > > Committed, except for this bit: Thanks. > +A statement-level trigger defined on partitioned tables is fired only > +once for

Re: [HACKERS] Declarative partitioning - another take

On Mon, May 1, 2017 at 12:18 AM, Amit Langote wrote: > Attached updated patch. Committed, except for this bit: +A statement-level trigger defined on partitioned tables is fired only +once for the table itself, not once for every table in the partitioning +

Re: [HACKERS] Declarative partitioning - another take

On 2017/04/29 6:56, David Fetter wrote: > On Fri, Apr 28, 2017 at 06:29:48PM +0900, Amit Langote wrote: >> On 2017/04/28 7:36, David Fetter wrote: >>> Did I notice correctly that there's no way to handle transition tables >>> for partitions in AFTER STATEMENT triggers? >> >> Did you mean to ask

Re: [HACKERS] Declarative partitioning - another take

Thanks for the review. On 2017/04/29 1:25, Robert Haas wrote: > On Fri, Apr 28, 2017 at 2:13 AM, Amit Langote > wrote: By the way, code changes I made in the attached are such that a subsequent patch could implement firing statement-level triggers of all

Re: [HACKERS] Declarative partitioning - another take

On Mon, Apr 24, 2017 at 07:43:29PM +0900, Amit Langote wrote: > On 2017/04/21 17:00, Rajkumar Raghuwanshi wrote: > > I am able to create statement triggers at root partition, but these > > triggers, not getting fired on updating partition. > It would be great if you could check if the patches fix

Re: [HACKERS] Declarative partitioning - another take

On Fri, Apr 28, 2017 at 06:29:48PM +0900, Amit Langote wrote: > On 2017/04/28 7:36, David Fetter wrote: > > On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote: > >> On 2017/04/27 1:52, Robert Haas wrote: > >>> On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote > >>>

Re: [HACKERS] Declarative partitioning - another take

On Fri, Apr 28, 2017 at 2:13 AM, Amit Langote wrote: > It seems to me that there is no difference in behavior between > inheritance-based and declarative partitioning as far as statement-level > triggers are concerned (at least currently). In both the cases, we

Re: [HACKERS] Declarative partitioning - another take

On 2017/04/28 7:36, David Fetter wrote: > On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote: >> On 2017/04/27 1:52, Robert Haas wrote: >>> On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote >>> wrote: FWIW, I too prefer the latter, that is, fire only the

Re: [HACKERS] Declarative partitioning - another take

Hi Rajkumar, On 2017/04/28 17:11, Rajkumar Raghuwanshi wrote: > On Fri, Apr 28, 2017 at 11:43 AM, Amit Langote < >> Updated patch attached. > > I have applied given patch, could see below behaviour with statement > trigger. > > When trying to delete value within partition range, triggers got

Re: [HACKERS] Declarative partitioning - another take

On Fri, Apr 28, 2017 at 11:43 AM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > Updated patch attached. > Hi Amit, I have applied given patch, could see below behaviour with statement trigger. When trying to delete value within partition range, triggers got fired (with zero row

Re: [HACKERS] Declarative partitioning - another take

Thanks for taking a look. On 2017/04/28 5:24, Robert Haas wrote: > On Wed, Apr 26, 2017 at 9:30 PM, Amit Langote > wrote: >>> Do we need to update the documentation? >> >> Yes, I think we should. How about as in the attached? > > Looks reasonable, but I was

Re: [HACKERS] Declarative partitioning - another take

On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote: > On 2017/04/27 1:52, Robert Haas wrote: > > On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote > > wrote: > >> FWIW, I too prefer the latter, that is, fire only the parent's triggers. > >> In that case,

Re: [HACKERS] Declarative partitioning - another take

On Wed, Apr 26, 2017 at 9:30 PM, Amit Langote wrote: >> Do we need to update the documentation? > > Yes, I think we should. How about as in the attached? Looks reasonable, but I was thinking you might also update the section which contrasts inheritance-based

Re: [HACKERS] Declarative partitioning - another take

On 2017/04/27 1:52, Robert Haas wrote: > On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote > wrote: >> FWIW, I too prefer the latter, that is, fire only the parent's triggers. >> In that case, applying only the patch 0001 will do. > > Do we need to update the

Re: [HACKERS] Declarative partitioning - another take

On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote wrote: > FWIW, I too prefer the latter, that is, fire only the parent's triggers. > In that case, applying only the patch 0001 will do. Do we need to update the documentation? -- Robert Haas EnterpriseDB:

Re: [HACKERS] Declarative partitioning - another take

On 26 April 2017 at 00:28, Robert Haas wrote: > So what I'd prefer -- on > the totally unprincipled basis that it would let us improve > performance in the future -- if you operate on a partition directly, > you fire the partition's triggers, but if you operate on the

Re: [HACKERS] Declarative partitioning - another take

Hi, Thanks for testing. On 2017/04/25 19:03, Rajkumar Raghuwanshi wrote: > Thanks for looking into it. I have applied fixes and checked for triggers. > I could see difference in behaviour of statement triggers for INSERT and > UPDATE, for insert only root partition triggers are getting fired but

Re: [HACKERS] Declarative partitioning - another take

On 2017/04/26 3:58, Robert Haas wrote: > On Mon, Apr 24, 2017 at 6:43 AM, Amit Langote > wrote: >> The reason it doesn't work is that we do not allocate ResultRelInfos for >> partitioned tables (not even for the root partitioned table in the >> update/delete cases),

Re: [HACKERS] Declarative partitioning - another take

On Mon, Apr 24, 2017 at 6:43 AM, Amit Langote wrote: > The reason it doesn't work is that we do not allocate ResultRelInfos for > partitioned tables (not even for the root partitioned table in the > update/delete cases), because the current implementation assumes

Re: [HACKERS] Declarative partitioning - another take

On Mon, Apr 24, 2017 at 4:13 PM, Amit Langote wrote: > Hi Rajkumar, > > It would be great if you could check if the patches fix the issues. > Hi Amit, Thanks for looking into it. I have applied fixes and checked for triggers. I could see difference in behaviour

Re: [HACKERS] Declarative partitioning - another take

Hi Rajkumar, Thanks for testing and the report. On 2017/04/21 17:00, Rajkumar Raghuwanshi wrote: > Hi, > > I have observed below with the statement triggers. > > I am able to create statement triggers at root partition, but these > triggers, not getting fired on updating partition. > > CREATE

Re: [HACKERS] Declarative partitioning - another take

Hi, I have observed below with the statement triggers. I am able to create statement triggers at root partition, but these triggers, not getting fired on updating partition. CREATE TABLE pt (a INT, b INT) PARTITION BY RANGE(a); CREATE TABLE pt1 PARTITION OF pt FOR VALUES FROM (1) to (7); CREATE

Re: [HACKERS] Declarative partitioning - another take

On 07.04.2017 13:05, Etsuro Fujita wrote: On 2016/12/14 16:20, Etsuro Fujita wrote: On 2016/12/09 19:46, Maksim Milyutin wrote: I would like to work on two tasks: - insert (and eventually update) tuple routing for foreign partition. - the ability to create an index on the parent and have all

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/14 16:20, Etsuro Fujita wrote: On 2016/12/09 19:46, Maksim Milyutin wrote: I would like to work on two tasks: - insert (and eventually update) tuple routing for foreign partition. - the ability to create an index on the parent and have all of the children inherit it; The first one

Re: [HACKERS] Declarative partitioning - another take

Hi Amit, On Thu, 23 Feb 2017 16:29:32 +0900 Amit Langote wrote: > Thanks for taking care of that. > > + * PartitionRoot relation descriptor for parent > relation > > Maybe: relation descriptor for root parent relation This seems

Re: [HACKERS] Declarative partitioning - another take

Nagata-san, On 2017/02/23 16:17, Yugo Nagata wrote: > Hi, > > I found that a comment for PartitionRoot in ResultRelInfo is missing. > Although this is trivial, since all other members have comments, I > think it is needed. Attached is the patch to fix it. Thanks for taking care of that. + *

Re: [HACKERS] Declarative partitioning - another take

Hi, I found that a comment for PartitionRoot in ResultRelInfo is missing. Although this is trivial, since all other members have comments, I think it is needed. Attached is the patch to fix it. Regards, Yugo Nagata On Tue, 27 Dec 2016 17:59:05 +0900 Amit Langote

Re: [HACKERS] Declarative partitioning - another take

On Fri, Feb 10, 2017 at 12:54 AM, Amit Langote wrote: > On 2017/02/09 15:22, amul sul wrote: >> About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch, >> following test is already covered in alter_table.sql @ Line # 1918, >> instead of this kindly add test

Re: [HACKERS] Declarative partitioning - another take

On 2017/02/09 15:22, amul sul wrote: > About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch, > following test is already covered in alter_table.sql @ Line # 1918, > instead of this kindly add test for list_partition: > > 77 +-- cannot drop NOT NULL constraint of a range partition key

Re: [HACKERS] Declarative partitioning - another take

About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch, following test is already covered in alter_table.sql @ Line # 1918, instead of this kindly add test for list_partition: 77 +-- cannot drop NOT NULL constraint of a range partition key column 78 +ALTER TABLE range_parted ALTER a

Re: [HACKERS] Declarative partitioning - another take

On 2017/02/08 21:20, amul sul wrote: > Regarding following code in ATExecDropNotNull function, I don't see > any special check for RANGE partitioned, is it intended to have same > restriction for LIST partitioned too, I guess not? > > /* > * If the table is a range partitioned table, check

Re: [HACKERS] Declarative partitioning - another take

Hi Amit, Regarding following code in ATExecDropNotNull function, I don't see any special check for RANGE partitioned, is it intended to have same restriction for LIST partitioned too, I guess not? /* * If the table is a range partitioned table, check that the column is not * in the

Re: [HACKERS] Declarative partitioning - another take

On Mon, Jan 30, 2017 at 4:42 PM, Peter Eisentraut wrote: > On 1/25/17 12:54 AM, Ashutosh Bapat wrote: >> The documentation available at >> https://www.postgresql.org/docs/devel/static/sql-createtable.html, >> does not make it clear that the lower bound of a range

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/31 6:42, Peter Eisentraut wrote: > On 1/25/17 12:54 AM, Ashutosh Bapat wrote: >> The documentation available at >> https://www.postgresql.org/docs/devel/static/sql-createtable.html, >> does not make it clear that the lower bound of a range partition is >> always inclusive and the higher

Re: [HACKERS] Declarative partitioning - another take

On 1/25/17 12:54 AM, Ashutosh Bapat wrote: > The documentation available at > https://www.postgresql.org/docs/devel/static/sql-createtable.html, > does not make it clear that the lower bound of a range partition is > always inclusive and the higher one is exclusive. I think a note in > section "

Re: [HACKERS] Declarative partitioning - another take

Hi Ashutosh, On 2017/01/25 14:54, Ashutosh Bapat wrote: > The documentation available at > https://www.postgresql.org/docs/devel/static/sql-createtable.html, > does not make it clear that the lower bound of a range partition is > always inclusive and the higher one is exclusive. I think a note in

Re: [HACKERS] Declarative partitioning - another take

The documentation available at https://www.postgresql.org/docs/devel/static/sql-createtable.html, does not make it clear that the lower bound of a range partition is always inclusive and the higher one is exclusive. I think a note in section " PARTITION OF parent_table FOR VALUES

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/25 5:55, Robert Haas wrote: > On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote > wrote: >> [ new patches ] > > Committed 0001 and 0002. See my earlier email for comments on 0003. It seems patches for all the issues mentioned in this thread so far, except

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/25 2:56, Robert Haas wrote: > On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote > wrote: >>> But I wonder why we don't instead just change this function to >>> consider tdhasoid rather than tdtypeid. I mean, if the only point of >>> comparing the type OIDs

Re: [HACKERS] Declarative partitioning - another take

Hi Keith, On 2017/01/20 12:40, Keith Fiske wrote: > So testing things out in pg_partman for native sub-partitioning and ran > into what is a bug for me that I know I have to fix, but I'm curious if > this can be prevented in the first place within the native partitioning > code itself. The below

Re: [HACKERS] Declarative partitioning - another take

On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote wrote: > [ new patches ] Committed 0001 and 0002. See my earlier email for comments on 0003. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] Declarative partitioning - another take

On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote wrote: >> But I wonder why we don't instead just change this function to >> consider tdhasoid rather than tdtypeid. I mean, if the only point of >> comparing the type OIDs is to find out whether the table-has-OIDs >>

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/21 6:29, Robert Haas wrote: > On Fri, Jan 20, 2017 at 1:15 AM, Andres Freund wrote: >> On 2017-01-19 14:18:23 -0500, Robert Haas wrote: >>> Committed. >> >> One of the patches around this topic committed recently seems to cause >> valgrind failures like >>

Re: [HACKERS] Declarative partitioning - another take

On Fri, Jan 20, 2017 at 1:15 AM, Andres Freund wrote: > On 2017-01-19 14:18:23 -0500, Robert Haas wrote: >> Committed. > > One of the patches around this topic committed recently seems to cause > valgrind failures like >

Re: [HACKERS] Declarative partitioning - another take

Hi Andres, On 2017/01/20 15:15, Andres Freund wrote: > On 2017-01-19 14:18:23 -0500, Robert Haas wrote: >> Committed. > > One of the patches around this topic committed recently seems to cause > valgrind failures like >

Re: [HACKERS] Declarative partitioning - another take

On 2017-01-19 14:18:23 -0500, Robert Haas wrote: > Committed. One of the patches around this topic committed recently seems to cause valgrind failures like https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2017-01-19%2008%3A40%3A02 : ==24969== Conditional jump or move depends on

Re: [HACKERS] Declarative partitioning - another take

So testing things out in pg_partman for native sub-partitioning and ran into what is a bug for me that I know I have to fix, but I'm curious if this can be prevented in the first place within the native partitioning code itself. The below shows a sub-partitioning set where the sub-partition has a

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/20 4:18, Robert Haas wrote: > On Thu, Jan 19, 2017 at 12:15 AM, Amit Langote wrote: >> 0002-Set-ecxt_scantuple-correctly-for-tuple-routing.patch >> >> In 2ac3ef7a01df859c62d0a02333b646d65eaec5ff, we changed things so that >> it's possible for a different TupleTableSlot to be used for

Re: [HACKERS] Declarative partitioning - another take

On Thu, Jan 19, 2017 at 12:15 AM, Amit Langote wrote: > 0001-Fix-a-bug-of-insertion-into-an-internal-partition.patch > > Since implicit partition constraints are not inherited, an internal > partition's constraint was not being enforced when targeted directly. > So,

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/19 14:15, Amit Langote wrote: > So, here are all the patches I posted to date (and one new at the bottom) > for reported and unreported bugs, excluding the one involving > BulkInsertState for which you replied in a new thread. > > I'll describe the attached patches in brief: Sorry, I

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/19 5:29, Robert Haas wrote: > On Wed, Jan 18, 2017 at 3:12 PM, Robert Haas wrote: >> On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote >> wrote: >>> [ updated patches ] >> >> I committed 0004 and also fixed the related regression test

Re: [HACKERS] Declarative partitioning - another take

On Wed, Jan 18, 2017 at 3:12 PM, Robert Haas wrote: > On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote > wrote: >> [ updated patches ] > > I committed 0004 and also fixed the related regression test not to > rely on DROP .. CASCADE, which isn't

Re: [HACKERS] Declarative partitioning - another take

On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote wrote: > [ updated patches ] I committed 0004 and also fixed the related regression test not to rely on DROP .. CASCADE, which isn't always stable. The remainder of this patch set needs a rebase, and perhaps you could

Re: [HACKERS] Declarative partitioning - another take

On Mon, Jan 16, 2017 at 4:09 AM, Amit Langote wrote: > The problem is that whereas the SlotValueDescription that we build to show > in the error message should be based on the tuple that was passed to > ExecInsert() or whatever NextCopyFrom() returned for CopyFrom()

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/14 6:24, Robert Haas wrote: > On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote wrote: >> >> Thanks! I realized however that the approach I used in 0002 of passing >> the original slot to ExecConstraints() fails in certain situations. For >> example, if a BR trigger changes the tuple, the

Re: [HACKERS] Declarative partitioning - another take

On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote wrote: > On 2017/01/05 5:50, Robert Haas wrote: >> On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote >> wrote: >>> Patches 0001 to 0006 unchanged. >> >> Committed 0001 earlier, as mentioned in

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/06 20:23, Amit Langote wrote: > On 2017/01/05 3:26, Robert Haas wrote: >> It's unclear to me why we need to do 0002. It doesn't seem like it >> should be necessary, it doesn't seem like a good idea, and the commit >> message you proposed is uninformative. > > If a single

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/05 5:50, Robert Haas wrote: > On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote > wrote: >> Patches 0001 to 0006 unchanged. > > Committed 0001 earlier, as mentioned in a separate email. Committed > 0002 and part of 0003. Thanks! I realized however that the

Re: [HACKERS] Declarative partitioning - another take

Hi Kieth, On 2017/01/10 14:44, Keith Fiske wrote: > Is there any reason for the exclusion of parent tables from the pg_tables > system catalog view? They do not show up in information_schema.tables as > well. I believe I found where to make the changes and I tested to make sure > it works for my

Re: [HACKERS] Declarative partitioning - another take

Hi Amul, On 2017/01/09 17:29, amul sul wrote: > I got server crash due to assert failure at ATTACHing overlap rang > partition, here is test case to reproduce this: > > CREATE TABLE test_parent(a int) PARTITION BY RANGE (a); > CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES >

Re: [HACKERS] Declarative partitioning - another take

Is there any reason for the exclusion of parent tables from the pg_tables system catalog view? They do not show up in information_schema.tables as well. I believe I found where to make the changes and I tested to make sure it works for my simple case. Attached is my first attempt at patching

Re: [HACKERS] Declarative partitioning - another take

Hi, I got server crash due to assert failure at ATTACHing overlap rang partition, here is test case to reproduce this: CREATE TABLE test_parent(a int) PARTITION BY RANGE (a); CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES FROM(100) TO(200); CREATE TABLE test_parent_part1(a

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/05 3:26, Robert Haas wrote: > On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote > wrote: >> On 2016/12/27 19:07, Amit Langote wrote: >>> Attached should fix that. >> >> Here are the last two patches with additional information like other >> patches. Forgot

Re: [HACKERS] Declarative partitioning - another take

Hi Keith, On 2017/01/06 2:16, Keith Fiske wrote: > Could we get some clarification on the partition_bound_spec portion of the > PARTITION OF clause? Just doing some testing it seems it's inclusive of the > FROM value but exclusive of the TO value. I don't see mention of this in > the docs as of

Re: [HACKERS] Declarative partitioning - another take

Could we get some clarification on the partition_bound_spec portion of the PARTITION OF clause? Just doing some testing it seems it's inclusive of the FROM value but exclusive of the TO value. I don't see mention of this in the docs as of commit 18fc5192a631441a73e6a3b911ecb14765140389 yesterday.

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/14 12:14, Venkata B Nagothi wrote: > Loading the data into a normal table is not an issue (infact the csv is > generated from the table itself) > > The issue is occurring only when i am trying to load the data from CSV file > into a partitioned table - > > db01=# CREATE TABLE

Re: [HACKERS] Declarative partitioning - another take

On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote wrote: > Patches 0001 to 0006 unchanged. Committed 0001 earlier, as mentioned in a separate email. Committed 0002 and part of 0003. But I'm skeptical that the as-patched-by-0003 logic in generate_partition_qual()

Re: [HACKERS] Declarative partitioning - another take

On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote wrote: > On 2016/12/27 19:07, Amit Langote wrote: >> Attached should fix that. > > Here are the last two patches with additional information like other > patches. Forgot to do that yesterday. 0001 has the disadvantage

Re: [HACKERS] Declarative partitioning - another take

On Mon, Dec 26, 2016 at 5:46 AM, Amit Langote wrote: > On 2016/12/23 8:08, Robert Haas wrote: >> On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote >> wrote: >>> While working on that, I discovered yet-another-bug having to do with the >>>

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/04 16:31, 高增琦 wrote: > Server crash(failed assertion) when two "insert" in one SQL: > > Step to reproduce: > create table t(a int, b int) partition by range(a); > create table t_p1 partition of t for values from (1) to (100); > create table t_p2 partition of t for values from (100) to

Re: [HACKERS] Declarative partitioning - another take

Server crash(failed assertion) when two "insert" in one SQL: Step to reproduce: create table t(a int, b int) partition by range(a); create table t_p1 partition of t for values from (1) to (100); create table t_p2 partition of t for values from (100) to (200); create table t_p3 partition of t for

Re: [HACKERS] Declarative partitioning - another take

On Wed, Jan 4, 2017 at 10:37 AM, Amit Langote wrote: > On 2017/01/03 19:04, Rajkumar Raghuwanshi wrote: > > On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote: > >> > >> Attached patch should fix the same. > > > > I have applied attached patch, server crash for

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/03 19:04, Rajkumar Raghuwanshi wrote: > On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote: >> >> Attached patch should fix the same. > > I have applied attached patch, server crash for range is fixed, but still > getting crash for multi-level list partitioning insert. > > postgres=#

Re: [HACKERS] Declarative partitioning - another take

On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote: > On 2016/12/27 18:30, Rajkumar Raghuwanshi wrote: > > Hi Amit, > > > > I have pulled latest sources from git and tried to create multi-level > > partition, getting a server crash, below are steps to reproduce.

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/27 19:07, Amit Langote wrote: > Attached should fix that. Here are the last two patches with additional information like other patches. Forgot to do that yesterday. Thanks, Amit >From 5a82b4caa6cec7845eb48e0397fab49c74b8dd98 Mon Sep 17 00:00:00 2001 From: amit

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/27 18:48, 高增琦 wrote: > Hi , > > I tried "COPY FROM" in the git version. It inserts rows to wrong partition. > > step to reproduce: > create table t(a int, b int) partition by range(a); > create table t_p1 partition of t for values from (1) to (100); > create table t_p2 partition of t

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/27 18:30, Rajkumar Raghuwanshi wrote: > Hi Amit, > > I have pulled latest sources from git and tried to create multi-level > partition, getting a server crash, below are steps to reproduce. please > check if it is reproducible in your machine also. > [ ... ] > postgres=# INSERT

Re: [HACKERS] Declarative partitioning - another take

Hi , I tried "COPY FROM" in the git version. It inserts rows to wrong partition. step to reproduce: create table t(a int, b int) partition by range(a); create table t_p1 partition of t for values from (1) to (100); create table t_p2 partition of t for values from (100) to (200); create table

Re: [HACKERS] Declarative partitioning - another take

Hi Amit, I have pulled latest sources from git and tried to create multi-level partition, getting a server crash, below are steps to reproduce. please check if it is reproducible in your machine also. postgres=# CREATE TABLE test_ml (a int, b int, c varchar) PARTITION BY RANGE(a); CREATE TABLE

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/26 19:46, Amit Langote wrote: > (Perhaps, the following should be its own new thread) > > I noticed that ExecProcessReturning() doesn't work properly after tuple > routing (example shows how returning tableoid currently fails but I > mention some other issues below): > > create table

Re: [HACKERS] Declarative partitioning - another take

Sorry about the delay in replying. On 2016/12/23 8:08, Robert Haas wrote: > On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote > wrote: >> While working on that, I discovered yet-another-bug having to do with the >> tuple descriptor that's used as we route a tuple down

Re: [HACKERS] Declarative partitioning - another take

On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote wrote: > While working on that, I discovered yet-another-bug having to do with the > tuple descriptor that's used as we route a tuple down a partition tree. If > attnums of given key attribute(s) are different on

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/22 1:50, Robert Haas wrote: > On Wed, Dec 21, 2016 at 5:33 AM, Amit Langote > wrote: >> Breaking changes into multiple commits/patches does not seem to work for >> adding regression tests. So, I've combined multiple patches into a single >> patch which

Re: [HACKERS] Declarative partitioning - another take

On Wed, Dec 21, 2016 at 5:33 AM, Amit Langote wrote: > Breaking changes into multiple commits/patches does not seem to work for > adding regression tests. So, I've combined multiple patches into a single > patch which is now patch 0002 in the attached set of

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/21 1:53, Robert Haas wrote: > On Mon, Dec 19, 2016 at 10:59 PM, Robert Haas wrote: >> On Sun, Dec 18, 2016 at 10:00 PM, Amit Langote >> wrote: >>> Here are updated patches including the additional information. >> >> Thanks.

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/21 14:03, Amit Langote wrote: > OK, updated patch attached. Oops, incomplete patch that was. Complete patch attached this time. Thanks, Amit diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index 1c219b03dd..115b98313e 100644 ---

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/21 13:42, Robert Haas wrote: > On Tue, Dec 20, 2016 at 9:14 PM, Amit Langote > wrote: >> On 2016/12/21 1:45, Alvaro Herrera wrote: >>> Robert Haas wrote: On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera wrote: >

Re: [HACKERS] Declarative partitioning - another take

On Tue, Dec 20, 2016 at 9:14 PM, Amit Langote wrote: > On 2016/12/21 1:45, Alvaro Herrera wrote: >> Robert Haas wrote: >>> On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera >>> wrote: Even if we decide to keep the message, I think it's

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/21 1:45, Alvaro Herrera wrote: > Robert Haas wrote: >> On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera >> wrote: >>> Even if we decide to keep the message, I think it's not very good >>> wording anyhow; as a translator I disliked it on sight. Instead of >>>

  1   2   3   4   >