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] Constraint exclusion failed to prune partition in case of partition expression involves function call

On 2017/02/02 21:09, amul sul wrote: > Hi, > > In following case, constraint exclusion not able prune partition (even > if function is immutable), is this know behaviour? Yes. The where condition in your example query does not specify the partition key column, so constraint exclusion won't

Re: [HACKERS] multivariate statistics (v19)

On 2017/01/31 6:57, Tomas Vondra wrote: > On 01/30/2017 09:37 PM, Alvaro Herrera wrote: >> Looks good to me. I don't think we need to keep the names very short -- >> I would propose "standistinct", "stahistogram", "stadependencies". >> > > Yeah, I got annoyed by the short names too. > > This

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

On 2017/01/25 5:55, Robert Haas wrote: > On Thu, Jan 19, 2017 at 9:58 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> [ new patches ] > > Committed 0001 and 0002. See my earlier email for comments on 0003. It seems patches for all the issues mentioned in th

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 > <langote_amit...@lab.ntt.co.jp> 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

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] contrib modules and relkind check

On 2017/01/24 15:11, Michael Paquier wrote: > On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Some contrib functions fail to fail sooner when relations of unsupported >> relkinds are passed, resulting in error message like one below

[HACKERS] contrib modules and relkind check

Some contrib functions fail to fail sooner when relations of unsupported relkinds are passed, resulting in error message like one below: create table foo (a int); create view foov as select * from foo; select pg_visibility('foov', 0); ERROR: could not open file "base/13123/16488": No such file

Re: [HACKERS] Declarative partitioning vs. BulkInsertState

On 2017/01/19 5:25, Robert Haas wrote: > On Wed, Jan 11, 2017 at 10:53 PM, Amit Langote wrote: >> On 2017/01/06 20:23, Amit Langote wrote: >>> >>> If a single BulkInsertState object is passed to >>> heap_insert()/heap_multi_insert() for different heaps corre

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] Valgrind-detected bug in partitioning code

On 2017/01/21 9:01, Tom Lane wrote: > Robert Haas writes: >> The difference is that those other equalBLAH functions call a >> carefully limited amount of code whereas, in looking over the >> backtrace you sent, I realized that equalPartitionDescs is calling >>

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/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 differen

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 b

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 <robertmh...@gmail.com> wrote: >> On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> [ updated patches ] >> >> I committed

Re: [HACKERS] Parallel Append implementation

Hi Amit, On 2016/12/23 14:21, Amit Khandekar wrote: > Currently an Append plan node does not execute its subplans in > parallel. There is no distribution of workers across its subplans. The > second subplan starts running only after the first subplan finishes, > although the individual subplans

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 B

Re: [HACKERS] [COMMITTERS] pgsql: Fix a bug in how we generate partition constraints.

On 2017/01/14 13:36, Amit Langote wrote: > On Sat, Jan 14, 2017 at 6:10 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Jan 13, 2017 at 3:09 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> >> wrote: >>> >>> I'm just saying that the pr

Re: [HACKERS] [COMMITTERS] pgsql: Fix a bug in how we generate partition constraints.

On Sat, Jan 14, 2017 at 6:10 AM, Robert Haas wrote: > On Fri, Jan 13, 2017 at 3:09 PM, Alvaro Herrera > wrote: >> >> I'm just saying that the problem at hand is already solved for a related >> feature, so ISTM this new code should use the

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 uninforma

[HACKERS] Obsolete reference to ParallelMain() in a comment

The comment above ParallelQueryMain() still refers to ParallelMain() as its caller which is no longer the case. Attached fixes that. Thanks, Amit diff --git a/src/backend/executor/execParallel.c b/src/backend/executor/execParallel.c index 86d9fb59ba..6cf62daab8 100644 ---

Re: [HACKERS] RustgreSQL

On 2017/01/11 8:02, Josh Berkus wrote: > On 01/09/2017 05:54 PM, Joel Jacobson wrote: >> On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby wrote: >>> I do wonder if there are parts of the codebase that would be much better >>> suited to a language other than C, and could

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 > <langote_amit...@lab.ntt.co.jp> wrote: >> Patches 0001 to 0006 unchanged. > > Committed 0001 earlier, as mentioned in a separate email. Committed > 0002 and part of 0003.

Re: [HACKERS] Declarative partitioning - another take

and relkind 'P' Currently, partitioned table are not taken into account in various information_schema and system views. Reported by: Keith Fiske Patch by: Kieth Fiske, Amit Langote Reports: https://www.postgresql.org/message-id/CAG1_KcDJiZB=l6youo_bvufj2q2851_xdkfhw0jdcd_2vtk...@mail.gmail.c

Re: [HACKERS] Declarative partitioning - another take

ind the first bound that is *equal* to the probe, because we don't have duplicate datums. That spends cycles needlessly. Per suggestion from Amul Sul. Reported by: Amul Sul Patch by: Amit Langote Reports: https://www.postgresql.org/message-id/CAAJ_b94XgbqVoXMyxxs63CaqWoMS1o2g

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 > <langote_amit...@lab.ntt.co.jp> wrote: >> On 2016/12/27 19:07, Amit Langote wrote: >>> Attached should fix that. >> >> Here are the last two patches with additional inf

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

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] ALTER TABLE parent SET WITHOUT OIDS and the oid column

On 2017/01/05 8:05, Tom Lane wrote: > Ashutosh Bapat writes: >> Right. But I think it's better to use attribute id, in case the code >> raising this error changes for any reason in future. > > I agree. The parent's "tdhasoid" flag is definitely based on 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

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 partitioni

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 <a

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

On 2016/12/27 22:24, Ashutosh Bapat wrote: > On Mon, Dec 26, 2016 at 3:36 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Attached patches modifies MergeAttributesIntoExisting() such that we >> increment attinhcount not only for user attributes, but also for

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

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): &g

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 > <langote_amit...@lab.ntt.co.jp> wrote: >> While working on that, I discovered yet-another-bug having to do with the >> tuple descriptor that's used

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

On 2016/12/26 19:06, Amit Langote wrote: > I suspect the following is a bug: A better subject line could be: "ALTER TABLE INHERIT and the oid column" Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

[HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

I suspect the following is a bug: create table foo (a int) with oids; CREATE TABLE create table bar (a int); CREATE TABLE alter table bar inherit foo; ERROR: table "bar" without OIDs cannot inherit from table "foo" with OIDs alter table bar set with oids; ALTER TABLE alter table bar inherit

Re: [HACKERS] Minor correction in alter_table.sgml

On Fri, Dec 23, 2016 at 12:07 AM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> (Of course, maybe the question we ought to be asking here is why >> ATTACH/DETACH PARTITION failed to go with the flow and be a >> combinable action.) > > I did wonder that

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 > <langote_amit...@lab.ntt.co.jp> wrote: >> Breaking changes into multiple commits/patches does not seem to work for >> adding regression tests. So, I've combined multiple patches into

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On 2016/12/22 0:31, Robert Haas wrote: > On Tue, Dec 20, 2016 at 12:22 PM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> Implement table partitioning. >> >> I thought it was odd to use rd_rel->reloftype as a boolean in >> ATExecAttachPartition, but apparently we do

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 <robertmh...@gmail.com> wrote: >> On Sun, Dec 18, 2016 at 10:00 PM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> Here are updated patches including the

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 --- a/src/backend/comma

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 > <langote_amit...@lab.ntt.co.jp> wrote: >> On 2016/12/21 1:45, Alvaro Herrera wrote: >>> Robert Haas wrote: >>>> On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrer

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 >>>

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/20 12:59, Robert Haas wrote: > On Sun, Dec 18, 2016 at 10:00 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Here are updated patches including the additional information. > > Thanks. Committed 0001. Will have to review the others when I'm les

Re: [HACKERS] Minor correction in alter_table.sgml

On 2016/12/20 4:08, Peter Eisentraut wrote: > On 11/30/16 8:47 PM, Amit Langote wrote: >>> So maybe something like >>> >>> All the forms of ALTER TABLE that act on a single table, >>> except RENAME and SET SCHEMA, can be combined into a >>>

Re: [HACKERS] Declarative partitioning vs. sql_inheritance

On 2016/12/17 10:40, Robert Haas wrote: > On Fri, Dec 16, 2016 at 7:39 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> On 12/16/16 11:05 AM, Robert Haas wrote: If we were going to do anything about this, my vote would be to

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/17 11:32, Amit Langote wrote: > On Sat, Dec 17, 2016 at 1:07 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Dec 16, 2016 at 3:02 AM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> Aside from the above, I found few other issue

Re: [HACKERS] Declarative partitioning - another take

On Sat, Dec 17, 2016 at 1:07 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Dec 16, 2016 at 3:02 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Aside from the above, I found few other issues and fixed them in the >> attached patches. Descrip

Re: [HACKERS] Declarative partitioning - another take

Hi Dmitry, On 2016/12/16 0:40, Dmitry Ivanov wrote: > Hi everyone, > > Looks like "sql_inheritance" GUC is affecting partitioned tables: > > explain (costs off) select * from test; > QUERY PLAN -- > Append > -> Seq Scan on test > -> Seq Scan

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/16 17:38, Greg Stark wrote: > Just poking around with partitioning. I notice that "\d parent" > doesn't list all the partitions, suggesting to use \d+ but a plain > "\d" does indeed list the partitions. That seems a bit strange and > also probably impractical if you have hundreds or

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/16 17:02, Amit Langote wrote: > [PATCH 2/7] Change how RelationGetPartitionQual() and related code works > > Since we always want to recurse, ie, include the parent's partition > constraint (if any), get rid of the argument recurse. > > Refactor out the code

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/14 1:32, Robert Haas wrote: > On Tue, Dec 13, 2016 at 1:58 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Attaching the above patch, along with some other patches posted earlier, >> and one more patch fixing another bug I found. Patch descrip

Re: [HACKERS] Transaction oddity with list partition of a list partition

Hi David, On 2016/12/15 18:09, David Fetter wrote: > Per Thomas Munro, could it be that the CREATE ... PARTITION OF ... code > fails to run CacheInvalidateRelcache on its parent(s)? Thomas's right. There is a patch posted for this issue [1]; I'm sending an updated version of the patch later

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/13 0:17, Tomas Vondra wrote: > On 12/12/2016 07:37 AM, Amit Langote wrote: >> >> Hi Tomas, >> >> On 2016/12/12 10:02, Tomas Vondra wrote: >>> >>> 2) I'm wondering whether having 'table' in the catalog name (and also in >>>

Re: [HACKERS] Declarative partitioning - another take

Hi, On 2016/12/13 2:45, Dmitry Ivanov wrote: > Huh, this code is broken as well. We have to ignore partitions that don't > have any subpartitions. Patch is attached below (v2). Good catch and thanks a lot for the patch! I have revised it a bit and added some explanatory comments to that

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/12 23:14, Peter Eisentraut wrote: > On 12/7/16 1:20 PM, Robert Haas wrote: >> I've committed 0001 - 0006 with that correction and a few other >> adjustments. There's plenty of room for improvement here, and almost >> certainly some straight-up bugs too, but I think we're at a point >>

Re: [HACKERS] multivariate statistics (v19)

Hi Tomas, On 2016/10/30 4:23, Tomas Vondra wrote: > Hi, > > Attached is v20 of the multivariate statistics patch series, doing mostly > the changes outlined in the preceding e-mail from October 11. > > The patch series currently has these parts: > > * 0001 : (FIX) teach pull_varno about

Re: [HACKERS] Declarative partitioning - another take

Hi Tomas, On 2016/12/12 10:02, Tomas Vondra wrote: > On 12/07/2016 07:20 PM, Robert Haas wrote: >> I've committed 0001 - 0006 with that correction and a few other >> adjustments. There's plenty of room for improvement here, and almost >> certainly some straight-up bugs too, but I think we're at

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On 2016/12/10 7:55, Keith Fiske wrote: > Working on a blog post for this feature and just found some more > inconsistencies with the doc examples. Looks like the city_id column was > defined in the measurements table when it should be in the cities table. > The addition of the partition to the

Re: [HACKERS] Declarative partitioning - another take

Hi, On 2016/12/11 10:02, Venkata B Nagothi wrote: > On Fri, Dec 9, 2016 at 11:11 PM, Amit Langote <amitlangot...@gmail.com> > wrote: >> On Fri, Dec 9, 2016 at 3:16 PM, Venkata B Nagothi <nag1...@gmail.com> >> wrote: >>> I am testing the partitioning

Re: [HACKERS] new table partitioning breaks \d table to older versions

On Sat, Dec 10, 2016 at 2:59 AM, Jeff Janes wrote: > Since: > > commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 > Author: Robert Haas > Date: Wed Dec 7 13:17:43 2016 -0500 > > Implement table partitioning. > > If I use psql compiled from 10devel

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

Hi Keith, On Sat, Dec 10, 2016 at 3:00 AM, Keith Fiske wrote: > Being that table partitioning is something I'm slightly interested in, > figured I'd give it a whirl. > > This example in the docs has an extraneous comma after the second column > > CREATE TABLE cities ( >

Re: [HACKERS] Declarative partitioning - another take

On Fri, Dec 9, 2016 at 3:16 PM, Venkata B Nagothi wrote: > Hi, > > I am testing the partitioning feature from the latest master and got the > following error while loading the data - > > db01=# create table orders_y1993 PARTITION OF orders FOR VALUES FROM > ('1993-01-01') TO

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/09 0:25, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:42 PM, Michael Paquier > wrote: >>> Congrats to everyone working on this! This is a large step forward. >> >> Congratulations to all! It was a long way to this result. > > Yes. The last effort in this

Re: [HACKERS] Declarative partitioning - another take

Hi Stephen, On 2016/12/08 22:35, Stephen Frost wrote: >>> * The fact that there's no implementation of row movement should be >>> documented as a limitation. We should also look at removing that >>> limitation. >> >> Yes, something to improve. By the way, since we currently mention INSERT >>

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/09 10:09, Tsunakawa, Takayuki wrote: > Another requirement was subpartitioning. Will this be possible with the > current infrastructure, or does this need drastic change? It does support sub-partitioning, although the syntax is a bit different. Thanks, Amit -- Sent via

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/08 3:20, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: >>> My bad. The fix I sent last night for one of the cache flush issues >>> wasn't quite right. The attached seems to fix it. >> Yes, fixed here too. Thanks. > > Thanks for the report

Re: [HACKERS] Declarative partitioning - another take

Hi Robert, On 2016/12/08 3:20, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: >>> My bad. The fix I sent last night for one of the cache flush issues >>> wasn't quite right. The attached seems to fix it. >> Yes, fixed here too. Thanks. > > Thanks

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On 2016/12/08 3:33, Robert Haas wrote: > On Wed, Dec 7, 2016 at 1:30 PM, Robert Haas wrote: >> -- partitioned table cannot partiticipate in regular inheritance >> CREATE TABLE partitioned2 ( >> a int >> --- 392,411 >> c text, >> d text >> ) PARTITION BY

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/08 1:53, Erik Rijkers wrote: > On 2016-12-07 17:38, Robert Haas wrote: >> On Wed, Dec 7, 2016 at 11:34 AM, Amit Langote <amitlangot...@gmail.com> >> wrote: >>>> begin; >>>> create schema if not exists s; >>>> create table s.t (

Re: [HACKERS] Declarative partitioning - another take

Hi Erik, On Thu, Dec 8, 2016 at 1:19 AM, Erik Rijkers <e...@xs4all.nl> wrote: > On 2016-12-07 12:42, Amit Langote wrote: > >> 0001-Catalog-and-DDL-for-partitioned-tables-20.patch >> 0002-psql-and-pg_dump-support-for-partitioned-tables-20.patch >> 0003-Catalog-a

Re: [HACKERS] Partitionning: support for Truncate Table WHERE

On 2016/12/07 15:26, Craig Ringer wrote: > On 7 December 2016 at 07:29, legrand legrand > wrote: > >> Working in a DSS environment, we often need to truncate table partitions >> regarding a WHERE condition and have to >> [...] >> Would be pleased to ear your feedback

Re: [HACKERS] Minor correction in alter_table.sgml

On 2016/12/01 1:17, Tom Lane wrote: > Stephen Frost writes: >> Seems like this would be a bit better: > >> -- >> All the actions, when acting on a single table and not using the ALL IN >> TABLESPACE form, except RENAME and SET SCHEMA, can be combined into a >> list of

Re: [HACKERS] Declarative partitioning - another take

On Thu, Dec 1, 2016 at 12:48 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Nov 25, 2016 at 5:49 AM, Amit Langote wrote: >> On 2016/11/25 11:44, Robert Haas wrote: >>> On Thu, Nov 24, 2016 at 6:13 AM, Amit Langote wrote: >>>> Also, it does nothi

Re: [HACKERS] Minor correction in alter_table.sgml

Hi Stephen, On Thu, Dec 1, 2016 at 12:24 AM, Stephen Frost <sfr...@snowman.net> wrote: > Amit, > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: >> Perhaps, it should say something like: >> >> All the actions except RENAME, SET TABLESPACE (when using the A

[HACKERS] Minor correction in alter_table.sgml

The following sentence in the ALTER TABLE documentation is not entirely accurate: "All the actions except RENAME, SET TABLESPACE and SET SCHEMA can be combined into a list of multiple alterations to apply in parallel." SET TABLESPACE (in the ALTER TABLE form) can be combined with other

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

Fujita-san, On 2016/11/30 17:25, Etsuro Fujita wrote: > On 2016/11/22 15:24, Etsuro Fujita wrote: >> On 2016/11/22 4:49, Tom Lane wrote: > >>> OK, please update the patch to handle those catalogs that way. > >> Will do. > > Done. I modified the patch so that any inval in pg_foreign_server

[HACKERS] Minor correction in alter_table.sgml

The following sentence in the ALTER TABLE documentation is not entirely accurate: "All the actions except RENAME, SET TABLESPACE and SET SCHEMA can be combined into a list of multiple alterations to apply in parallel." SET TABLESPACE (in the ALTER TABLE form) can be combined with other

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/17 20:27, Amit Langote wrote: > On 2016/11/16 4:21, Robert Haas wrote: >> Have you done any performance testing on the tuple routing code? >> Suppose we insert a million (or 10 million) tuples into an >> unpartitioned table, a table with 10 partitions, a table w

[HACKERS] Thinko in set_rel_consider_parallel()

The following looks like a thinko, which fixed in attached: -Oid proparallel = func_parallel(... +charproparallel = func_parallel(... Thanks, Amit diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index

Re: [HACKERS] Fix comment in build_simple_rel

On 2016/11/29 3:57, Alvaro Herrera wrote: > Amit Langote wrote: >> Attached fixes reference in a comment to a non-existent function: >> >> s/GetRelationInfo/get_relation_info/g > > Thanks, pushed. get_relation_info() itself had been neglected when this > responsibil

[HACKERS] Fix comment in build_simple_rel

Attached fixes reference in a comment to a non-existent function: s/GetRelationInfo/get_relation_info/g Thanks, Amit diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c index deef560..d5326e6 100644 --- a/src/backend/optimizer/util/relnode.c +++

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/25 11:44, Robert Haas wrote: > On Thu, Nov 24, 2016 at 6:13 AM, Amit Langote wrote: >> Also, it does nothing to help the undesirable situation that one can >> insert a row with a null partition key (expression) into any of the range >> partitions if targeted dir

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/25 13:51, Ashutosh Bapat wrote: >> >> I assume you meant "...right after the column name"? >> >> I will modify the grammar to allow that way then, so that the following >> will work: >> >> create table p1 partition of p ( >> a primary key >> ) for values in (1); >> > > That seems

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/25 4:36, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2016/11/24 15:10, Ashutosh Bapat wrote: >>> On Thu, Nov 24, 2016 at 11:34 AM, Amit Langote wrote: > >>>> You have to specify column constraints using the keywords WITH OPTIONS, >>&

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/23 4:50, Robert Haas wrote: > On Tue, Nov 22, 2016 at 4:15 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >>> The easiest thing to do might be to just enforce that all of the >>> partition key columns have to be not-null when the range-pa

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/24 15:10, Ashutosh Bapat wrote: > On Thu, Nov 24, 2016 at 11:34 AM, Amit Langote wrote: >> On 2016/11/24 14:35, Ashutosh Bapat wrote: >>> IIUC, it should allow "create table t1_p1 partition of t1 (a primary >>> key) ...", (a primary key) is nothing b

Re: [HACKERS] Declarative partitioning - another take

Hi Ashutosh, On 2016/11/24 14:35, Ashutosh Bapat wrote: > I am trying to create a partitioned table with primary keys on the > partitions. Here's the corresponding syntax as per documentation > CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ > IF NOT EXISTS ] table_name >

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: >> OK, I will share the performance results soon. > > Thanks. > >>> Also, in 0006: >>> >>> - I doubt that PartitionTreeNodeData's header comment will s

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/11 20:49, Ashutosh Bapat wrote: > I have not looked at the latest set of patches, but in the version > that I have we create one composite type for every partition. This > means that if there are thousand partitions, there will be thousand > identical entries in pg_type. Since all the

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/04 0:49, Robert Haas wrote: > On Thu, Nov 3, 2016 at 7:46 AM, <alvhe...@alvh.no-ip.org> wrote: >> El 2016-10-28 07:53, Amit Langote escribió: >>> @@ -6267,6 +6416,12 @@ ATAddForeignKeyConstraint(AlteredTableInfo *tab, >>> Relation rel, >>>

Re: [HACKERS] Declarative partitioning - another take

I forgot to quote your comments in the email I sent on Friday [1], with new patches that do take care of the following comments. On 2016/11/11 4:04, Robert Haas wrote: > On Thu, Nov 10, 2016 at 7:40 AM, Amit Langote >> >> OK, "partition key" and "partitioning me

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/10 2:00, Robert Haas wrote: > In this latest patch set: > > src/backend/parser/parse_utilcmd.c:3194: indent with spaces. > +*rdatum; This one I will fix. > > With all patches applied, "make check" fails with a bunch of diffs > that look like this:

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Nov 9, 2016 at 1:44 PM, Tom Lane wrote: >>> I don't think we need "named constants", especially not >>> manually-maintained ones. The thing

Re: [HACKERS] Declarative partitioning - another take

Hi Jaime, On 2016/11/08 2:15, Jaime Casanova wrote: > On 28 October 2016 at 02:53, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > I started to review the functionality of this patch, so i applied all > 9 patches. After that i found this warning, which i guess

Re: [HACKERS] Declarative partitioning - another take

Hi Jaime, On 2016/11/08 2:24, Jaime Casanova wrote: > On 7 November 2016 at 12:15, Jaime Casanova > <jaime.casan...@2ndquadrant.com> wrote: >> On 28 October 2016 at 02:53, Amit Langote <langote_amit...@lab.ntt.co.jp> >> wrote: >>> >>> Please

<    2   3   4   5   6   7   8   9   10   11   >