Re: [HACKERS] Partitioned tables and relfilenode

On 2017/04/13 0:36, Robert Haas wrote: > On Tue, Apr 11, 2017 at 10:15 PM, Amit Langote > wrote: >> Alright. So I made it into two patches instead: 0001 fixes the bug that >> validateCheckConstraint() tries to scan partitioned tables and 0002 makes >> trying to

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Apr 11, 2017 at 10:15 PM, Amit Langote wrote: > Alright. So I made it into two patches instead: 0001 fixes the bug that > validateCheckConstraint() tries to scan partitioned tables and 0002 makes > trying to convert a partitioned table to a view a user

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/04/12 2:41, Robert Haas wrote: > On Tue, Apr 11, 2017 at 9:45 AM, Tom Lane wrote: >> Amit Langote writes: >>> 2. DefineQueryRewrite() may try to scan a partitioned table in the case of >>> converting a table to view, where we must make

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Apr 11, 2017 at 9:45 AM, Tom Lane wrote: > Amit Langote writes: >> 2. DefineQueryRewrite() may try to scan a partitioned table in the case of >> converting a table to view, where we must make sure that the table being >> converted is

Re: [HACKERS] Partitioned tables and relfilenode

Amit Langote writes: > 2. DefineQueryRewrite() may try to scan a partitioned table in the case of > converting a table to view, where we must make sure that the table being > converted is empty. It's checked by scanning the heap, which we should > not do for a

Re: [HACKERS] Partitioned tables and relfilenode

Looking at the number of issues where we have to fix tests based on the relkind checks, I think, we have to consider creating macros as described in my reply to thread with subject " Allowing extended stats on foreign and partitioned tables". On Tue, Apr 11, 2017 at 2:46 PM, Amit Langote

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/04/03 11:39, Amit Langote wrote: > On 2017/04/01 5:29, Robert Haas wrote: >> Thanks for reviewing, and thanks to Maksim as well, and thanks to Amit >> for writing the patch. > > Thanks for committing. :) I noticed that I had missed a couple of places that would try to scan partitioned

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/04/01 5:29, Robert Haas wrote: > On Fri, Mar 31, 2017 at 4:33 AM, Kyotaro HORIGUCHI > wrote: >> I have no more comment on this. Thank you. > > I committed this with a few tweaks. I simplified the wording in the > documentation a bit, removed or adjusted

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Mar 31, 2017 at 4:33 AM, Kyotaro HORIGUCHI wrote: > I have no more comment on this. Thank you. I committed this with a few tweaks. I simplified the wording in the documentation a bit, removed or adjusted a couple of comments, and slightly changed the way

Re: [HACKERS] Partitioned tables and relfilenode

At Fri, 31 Mar 2017 16:17:05 +0900, Amit Langote wrote in <2dec1acb-6e2f-5aa5-0e26-fcc172ce9...@lab.ntt.co.jp> > Horiguchi-san, > > On 2017/03/31 15:50, Kyotaro HORIGUCHI wrote: > > At Thu, 30 Mar 2017 20:58:35 +0900, Amit Langote wrote: > >> Updated patch

Re: [HACKERS] Partitioned tables and relfilenode

Horiguchi-san, On 2017/03/31 15:50, Kyotaro HORIGUCHI wrote: > At Thu, 30 Mar 2017 20:58:35 +0900, Amit Langote wrote: >> Updated patch attached. > > Thank you. > > - Applies cleanly on master (f90d23d) > - Compiled without error > - Code seems fine. > - Documentaion seems fine.. for me. > -

Re: [HACKERS] Partitioned tables and relfilenode

At Thu, 30 Mar 2017 20:58:35 +0900, Amit Langote wrote in > Thanks for the review. > > On Thu, Mar 30, 2017 at 7:37 PM, Kyotaro HORIGUCHI wrote: > > At Thu, 30 Mar 2017 18:24:16 +0900, Amit Langote

Re: [HACKERS] Partitioned tables and relfilenode

Thanks for the review. On Thu, Mar 30, 2017 at 7:37 PM, Kyotaro HORIGUCHI wrote: > At Thu, 30 Mar 2017 18:24:16 +0900, Amit Langote wrote: >> On 2017/03/29 23:58, Robert Haas wrote: >> > On Wed, Mar 29, 2017 at 4:21 AM, Amit Langote >> > wrote: >> >> Looks correct,

Re: [HACKERS] Partitioned tables and relfilenode

Hello, At Thu, 30 Mar 2017 18:24:16 +0900, Amit Langote wrote in > On 2017/03/29 23:58, Robert Haas wrote: > > On Wed, Mar 29, 2017 at 4:21 AM, Amit Langote > > wrote: > >> Looks

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/29 23:58, Robert Haas wrote: > On Wed, Mar 29, 2017 at 4:21 AM, Amit Langote > wrote: >> Looks correct, so incorporated in the attached updated patch. Thanks. > > This seems like a hacky way to limit the reloptions to just OIDs. > Shouldn't we instead

Re: [HACKERS] Partitioned tables and relfilenode

On Wed, Mar 29, 2017 at 4:21 AM, Amit Langote wrote: > Looks correct, so incorporated in the attached updated patch. Thanks. This seems like a hacky way to limit the reloptions to just OIDs. Shouldn't we instead have a new RELOPT_KIND_PARTITIONED or something like

Re: [HACKERS] Partitioned tables and relfilenode

At Wed, 29 Mar 2017 17:21:26 +0900, Amit Langote wrote in > > Thanks for taking a look. This patch is small enough to look at in a short time:p > > The following attracted my eyes. > > > > + if

Re: [HACKERS] Partitioned tables and relfilenode

Horiguchi-san, Thanks for taking a look. On 2017/03/29 16:49, Kyotaro HORIGUCHI wrote: > At Wed, 29 Mar 2017 15:40:20 +0900, Amit Langote wrote: >> On 2017/03/27 23:27, Robert Haas wrote: And here is the updated patch. >>> >>> I think you should go back to the earlier strategy of

Re: [HACKERS] Partitioned tables and relfilenode

Hello, At Wed, 29 Mar 2017 15:40:20 +0900, Amit Langote wrote in > On 2017/03/27 23:27, Robert Haas wrote: > > On Thu, Mar 23, 2017 at 8:54 PM, Amit Langote > > wrote: > >> On

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/27 23:27, Robert Haas wrote: > On Thu, Mar 23, 2017 at 8:54 PM, Amit Langote > wrote: >> On 2017/03/23 23:47, Amit Langote wrote: >>> On Thu, Mar 23, 2017 at 11:27 PM, Maksim Milyutin >>> wrote: Hi! I have

Re: [HACKERS] Partitioned tables and relfilenode

On Mon, Mar 27, 2017 at 8:59 PM, Amit Langote wrote: > Oops, my bad. I will include it in the patch I'll send after addressing > Robert's comments. Thanks again! That patch coming soon? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Partitioned tables and relfilenode

Hi, On 2017/03/28 0:13, Maksim Milyutin wrote: > On 24.03.2017 03:54, Amit Langote wrote: >> >> And here is the updated patch. >> > > Perhaps you forgot my fix in the updated patch > > diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c > index 3999e6e..36917c8 100644 > ---

Re: [HACKERS] Partitioned tables and relfilenode

On 24.03.2017 03:54, Amit Langote wrote: And here is the updated patch. Perhaps you forgot my fix in the updated patch diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c index 3999e6e..36917c8 100644 --- a/src/backend/catalog/heap.c +++ b/src/backend/catalog/heap.c @@

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Mar 23, 2017 at 8:54 PM, Amit Langote wrote: > On 2017/03/23 23:47, Amit Langote wrote: >> On Thu, Mar 23, 2017 at 11:27 PM, Maksim Milyutin >> wrote: >>> Hi! >>> >>> I have noticed that there is scheduled unlinking of nonexistent

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/23 23:47, Amit Langote wrote: > On Thu, Mar 23, 2017 at 11:27 PM, Maksim Milyutin > wrote: >> Hi! >> >> I have noticed that there is scheduled unlinking of nonexistent physical >> storage under partitioned table when we execute DROP TABLE statement on this >>

Re: [HACKERS] Partitioned tables and relfilenode

Hi, On Thu, Mar 23, 2017 at 11:27 PM, Maksim Milyutin wrote: > Hi! > > I have noticed that there is scheduled unlinking of nonexistent physical > storage under partitioned table when we execute DROP TABLE statement on this > partitioned table. Though this action

Re: [HACKERS] Partitioned tables and relfilenode

Hi! I have noticed that there is scheduled unlinking of nonexistent physical storage under partitioned table when we execute DROP TABLE statement on this partitioned table. Though this action doesn't generate any error under typical behavior of postgres because the error of storage's lack is

Re: [HACKERS] Partitioned tables and relfilenode

> On Tue, Mar 21, 2017 at 10:37 AM, Robert Haas wrote: >> On Tue, Mar 21, 2017 at 9:49 AM, Robert Haas wrote: >>> On Tue, Mar 21, 2017 at 5:05 AM, Amit Langote >>> wrote: Attached updated patches. >>> >>>

Re: [HACKERS] Partitioned tables and relfilenode

Off-list by accident. Re-adding the list. On Tue, Mar 21, 2017 at 10:37 AM, Robert Haas wrote: > On Tue, Mar 21, 2017 at 9:49 AM, Robert Haas wrote: >> On Tue, Mar 21, 2017 at 5:05 AM, Amit Langote >> wrote: >>>

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Mar 21, 2017 at 1:21 PM, Simon Riggs wrote: >> The decision not to require the attribute numbers to match doesn't >> necessarily mean we can't get rid of the Append node, though. First >> of all, in a lot of practical cases the attribute numbers will all >> match.

Re: [HACKERS] Partitioned tables and relfilenode

On 21 March 2017 at 16:33, Robert Haas wrote: > On Tue, Mar 21, 2017 at 12:19 PM, Simon Riggs wrote: >> On 16 March 2017 at 10:03, Amit Langote >> wrote: >>> On 2017/03/15 7:09, Robert Haas wrote: >> I think that

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Mar 21, 2017 at 12:19 PM, Simon Riggs wrote: > On 16 March 2017 at 10:03, Amit Langote wrote: >> On 2017/03/15 7:09, Robert Haas wrote: > >>> I think that eliding the Append node when there's only one child may >>> be unsafe in the

Re: [HACKERS] Partitioned tables and relfilenode

On 16 March 2017 at 10:03, Amit Langote wrote: > On 2017/03/15 7:09, Robert Haas wrote: >> I think that eliding the Append node when there's only one child may >> be unsafe in the case where the child's attribute numbers are >> different from the parent's attribute

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Mar 21, 2017 at 5:05 AM, Amit Langote wrote: > Attached updated patches. Committed 0001 after removing a comma. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/21 1:16, Robert Haas wrote: > On Fri, Mar 17, 2017 at 4:57 AM, Amit Langote > wrote: >>> Yes, but on the flip side, you're having to add code in a lot of >>> places -- I think I counted 7 -- where you turn around and ignore >>> those AppendRelInfos. >> >>

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Mar 17, 2017 at 4:57 AM, Amit Langote wrote: >> Yes, but on the flip side, you're having to add code in a lot of >> places -- I think I counted 7 -- where you turn around and ignore >> those AppendRelInfos. > > Perhaps you were looking at the previous

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/16 22:16, Robert Haas wrote: > On Thu, Mar 16, 2017 at 6:03 AM, Amit Langote > wrote: >> I think we'll need to store *somewhere* the mapping of which inh=false >> partitioned table RTE is the child of which inh=true (IOW, parent) >> partitioned table RTE.

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Mar 16, 2017 at 6:03 AM, Amit Langote wrote: > I think we'll need to store *somewhere* the mapping of which inh=false > partitioned table RTE is the child of which inh=true (IOW, parent) > partitioned table RTE. I mean, for the children you're going to

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/15 7:09, Robert Haas wrote: > On Mon, Mar 13, 2017 at 6:24 AM, Amit Langote > wrote: >> The previous proposal was for expand_inherited_rtentry to not create RT >> entries and AppendRelInfo's for the non-leaf tables, but I think that >> doesn't work, as I

Re: [HACKERS] Partitioned tables and relfilenode

>> >> Will it help to retain the partition hierarchy as inheritance >> hierarchy and then collapse it while creating append paths. That will >> be needed by partition-wise join, will be helpful in partition pruning >> without using constraints and so on. So, may be could use that >> infrastructure

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/15 13:38, Ashutosh Bapat wrote: > On Wed, Mar 15, 2017 at 3:39 AM, Robert Haas wrote: >> On Mon, Mar 13, 2017 at 6:24 AM, Amit Langote >> wrote: >>> The previous proposal was for expand_inherited_rtentry to not create RT >>>

Re: [HACKERS] Partitioned tables and relfilenode

On Wed, Mar 15, 2017 at 3:39 AM, Robert Haas wrote: > On Mon, Mar 13, 2017 at 6:24 AM, Amit Langote > wrote: >> The previous proposal was for expand_inherited_rtentry to not create RT >> entries and AppendRelInfo's for the non-leaf tables,

Re: [HACKERS] Partitioned tables and relfilenode

On Mon, Mar 13, 2017 at 6:24 AM, Amit Langote wrote: > The previous proposal was for expand_inherited_rtentry to not create RT > entries and AppendRelInfo's for the non-leaf tables, but I think that > doesn't work, as I tried to explain above. We need RTEs because

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/13 19:30, Amit Langote wrote: >> Here is the updated patch. >> >> Since this patch proposes to avoid creating scan nodes for non-leaf tables >> in a partition tree, they won't be referenced anywhere in the resulting >> plan tree. So the executor will not lock those tables in the >>

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/13 19:24, Amit Langote wrote: > On 2017/03/10 17:57, Amit Langote wrote: >> On 2017/03/08 22:36, Robert Haas wrote: >>> On Wed, Mar 8, 2017 at 5:36 AM, Amit Langote wrote: > -rel = mtstate->resultRelInfo->ri_RelationDesc; > +nominalRTE = rt_fetch(node->nominalRelation,

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/10 17:57, Amit Langote wrote: > On 2017/03/08 22:36, Robert Haas wrote: >> On Wed, Mar 8, 2017 at 5:36 AM, Amit Langote wrote: -rel = mtstate->resultRelInfo->ri_RelationDesc; +nominalRTE = rt_fetch(node->nominalRelation, estate->es_range_table); +nominalRel =

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/08 22:36, Robert Haas wrote: > On Wed, Mar 8, 2017 at 5:36 AM, Amit Langote wrote: >>> -rel = mtstate->resultRelInfo->ri_RelationDesc; >>> +nominalRTE = rt_fetch(node->nominalRelation, estate->es_range_table); >>> +nominalRel = heap_open(nominalRTE->relid, NoLock); >>> >>>

Re: [HACKERS] Partitioned tables and relfilenode

On Wed, Mar 8, 2017 at 5:36 AM, Amit Langote wrote: >> I don't quite understand the need for the change to set_rel_size(). >> The rte->inh case is handled before reaching the new code, and IIUC >> the !rte->inh case should never happen given the changes to >>

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/08 2:27, Robert Haas wrote: > On Tue, Mar 7, 2017 at 12:11 AM, Ashutosh Bapat > wrote: >> I see that all the changes by Amit and myself to what was earlier 0003 >> patch are now part of 0002 patch. The patch looks ready for committer. > > Reviewing

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Mar 7, 2017 at 12:11 AM, Ashutosh Bapat wrote: > I see that all the changes by Amit and myself to what was earlier 0003 > patch are now part of 0002 patch. The patch looks ready for committer. Reviewing 0002: This patch seems to have falsified the header

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Mar 2, 2017 at 8:02 PM, Amit Langote wrote: > Thanks. I noticed that 'and' is duplicated in a line added by the commit > to analyze.sgml. Attached 0001 fixes that. 0002 and 0003 same as the > last version. Oh, rats. Thanks for noticing. Committed 0001.

Re: [HACKERS] Partitioned tables and relfilenode

I see that all the changes by Amit and myself to what was earlier 0003 patch are now part of 0002 patch. The patch looks ready for committer. Some comments about 0003 patch. CREATE TABLE syntax seems to allow specifying reloptions for a partitioned table. But extractRelOptions() and

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/06 17:22, Michael Paquier wrote: > On Mon, Mar 6, 2017 at 4:18 PM, Amit Langote > wrote: >> About autovacuum_* parameters - we currently don't handle partitioned >> tables in autovacuum.c, because no statistics are reported for them. That >> is,

Re: [HACKERS] Partitioned tables and relfilenode

> > We can leave it for the committer to decide, maybe. Committers often > rewrite surrounding comments to improve wording, correcting factual > errors, etc. > Sure. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/06 17:01, Ashutosh Bapat wrote: > On Mon, Mar 6, 2017 at 1:26 PM, Amit Langote > wrote: >> On 2017/03/06 16:49, Ashutosh Bapat wrote: >>> On Mon, Mar 6, 2017 at 12:48 PM, Amit Langote wrote: On 2017/03/06 15:41, Michael Paquier wrote: > This

Re: [HACKERS] Partitioned tables and relfilenode

On Mon, Mar 6, 2017 at 4:18 PM, Amit Langote wrote: > About autovacuum_* parameters - we currently don't handle partitioned > tables in autovacuum.c, because no statistics are reported for them. That > is, relation_needs_vacanalyze() will never return true for

Re: [HACKERS] Partitioned tables and relfilenode

On Mon, Mar 6, 2017 at 1:26 PM, Amit Langote wrote: > On 2017/03/06 16:49, Ashutosh Bapat wrote: >> On Mon, Mar 6, 2017 at 12:48 PM, Amit Langote wrote: >>> On 2017/03/06 15:41, Michael Paquier wrote: This comment is not completely correct. Children can be temp

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/06 16:49, Ashutosh Bapat wrote: > On Mon, Mar 6, 2017 at 12:48 PM, Amit Langote wrote: >> On 2017/03/06 15:41, Michael Paquier wrote: >>> This comment is not completely correct. Children can be temp tables, >>> they just cannot be temp tables of other backends. It seems to me that >>>

Re: [HACKERS] Partitioned tables and relfilenode

On Mon, Mar 6, 2017 at 12:48 PM, Amit Langote wrote: > Thanks for the review. > > On 2017/03/06 15:41, Michael Paquier wrote: >> On Fri, Mar 3, 2017 at 10:02 AM, Amit Langote >> wrote: >>> Thanks. I noticed that 'and' is duplicated

Re: [HACKERS] Partitioned tables and relfilenode

Thanks for the review. On 2017/03/06 15:41, Michael Paquier wrote: > On Fri, Mar 3, 2017 at 10:02 AM, Amit Langote > wrote: >> Thanks. I noticed that 'and' is duplicated in a line added by the commit >> to analyze.sgml. Attached 0001 fixes that. 0002 and 0003

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Mar 3, 2017 at 10:02 AM, Amit Langote wrote: > Thanks. I noticed that 'and' is duplicated in a line added by the commit > to analyze.sgml. Attached 0001 fixes that. 0002 and 0003 same as the > last version. /* -* If all the children were temp

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/02 21:48, Robert Haas wrote: > On Thu, Mar 2, 2017 at 3:52 PM, Amit Langote > wrote: >>> think we should omit this logic (and change the documentation to >>> match). That is, a database-wide ANALYZE should update the statistics >>> for each child as well

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Mar 2, 2017 at 3:52 PM, Amit Langote wrote: >> think we should omit this logic (and change the documentation to >> match). That is, a database-wide ANALYZE should update the statistics >> for each child as well as for the parent. Otherwise direct queries

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/02 18:36, Robert Haas wrote: > On Tue, Feb 28, 2017 at 11:35 AM, Amit Langote wrote: >>> In acquire_inherited_sample_rows(), instead of inserting a whole >>> stanza of logic just above the existing dispatch on relkind, I think >>> we can get by with a very slightly update to what's

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Feb 28, 2017 at 11:35 AM, Amit Langote wrote: > How about the documentation changes in the attached updated 0001? I know > that this page needs a much larger rewrite as we are discussing in the > other thread. Looks good. >> In

Re: [HACKERS] Partitioned tables and relfilenode

Thanks for the review. I was just about to send a new version of the patches. On 2017/02/28 12:20, Robert Haas wrote: > On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote > wrote: >> Thanks for the review. > > In 0001, the documentation which you are patching has a

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/28 13:52, Ashutosh Bapat wrote: > Amit's original patch had an assertion failure in > extract_autovac_opts(). His patch adds partitioned tables in the list > of tables to be auto-analyzed. But there's an assertion in > extract_autovac_opts(), which did not consider partitioned tables. >

Re: [HACKERS] Partitioned tables and relfilenode

Amit's original patch had an assertion failure in extract_autovac_opts(). His patch adds partitioned tables in the list of tables to be auto-analyzed. But there's an assertion in extract_autovac_opts(), which did not consider partitioned tables. When a partitioned table is created, the assertion

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/28 12:29, Michael Paquier wrote: > On Tue, Feb 28, 2017 at 12:23 PM, Bruce Momjian wrote: >> I am a little confused by the above. Is a partitioned table the parent >> or the children? Reading the code it seems it is the parent, which >> explains why it works. Can I

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Feb 28, 2017 at 12:23 PM, Bruce Momjian wrote: > I am a little confused by the above. Is a partitioned table the parent > or the children? Reading the code it seems it is the parent, which > explains why it works. Can I clarify that? As I understand things, a

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Feb 28, 2017 at 11:53:16AM +0900, Amit Langote wrote: > > I don't think we are doing this, but if the parent table doesn't have a > > physical file pg_upgrade will need to be taught that. We have that case > > now for unlogged tables on standby servers that we need to address. > >

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote: > Thanks for the review. In 0001, the documentation which you are patching has a section for limitations that apply only to both partitioning and constraint exclusion, and another for limitations that apply only

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/28 3:54, Bruce Momjian wrote: > On Fri, Feb 10, 2017 at 03:19:47PM +0900, Amit Langote wrote: >> The new partitioned tables do not contain any data by themselves. Any >> data inserted into a partitioned table is routed to and stored in one of >> its partitions. In fact, it is

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Feb 10, 2017 at 03:19:47PM +0900, Amit Langote wrote: > The new partitioned tables do not contain any data by themselves. Any > data inserted into a partitioned table is routed to and stored in one of > its partitions. In fact, it is impossible to insert *any* data before a > partition

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Feb 23, 2017 at 1:38 PM, Amit Langote wrote: > On 2017/02/23 16:48, Ashutosh Bapat wrote: >> On Thu, Feb 23, 2017 at 1:08 PM, Amit Langote wrote: >>> @@ -996,10 +996,20 @@ inheritance_planner(PlannerInfo *root) >>> /* >>> +* Partitioned

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/23 16:48, Ashutosh Bapat wrote: > On Thu, Feb 23, 2017 at 1:08 PM, Amit Langote wrote: >> @@ -996,10 +996,20 @@ inheritance_planner(PlannerInfo *root) >> /* >> +* Partitioned tables do not have storage for themselves and should >> not be >> +* scanned. >> >> @@

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Feb 23, 2017 at 1:08 PM, Amit Langote wrote: > Thanks for the review. > > On 2017/02/23 15:44, Ashutosh Bapat wrote: >> On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote: >>> Rewrote that comment block as: >>> >>> * >>> * If the parent is a

Re: [HACKERS] Partitioned tables and relfilenode

Thanks for the review. On 2017/02/23 15:44, Ashutosh Bapat wrote: > On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote: >> Rewrote that comment block as: >> >> * >> * If the parent is a partitioned table, we already set the nominal >> * relation. >> */ >> > > I reworded

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote: > Thanks for the review. > > On 2017/02/22 21:58, Ashutosh Bapat wrote: Also we should add tests to make sure the scans on partitioned tables without any partitions do not get into problems. PFA patch

Re: [HACKERS] Partitioned tables and relfilenode

Thanks for the review. On 2017/02/22 21:58, Ashutosh Bapat wrote: >>> Also we should add tests to make sure the scans on partitioned tables >>> without any partitions do not get into problems. PFA patch which adds >>> those tests. >> >> I added the test case you suggest, but kept just the first

Re: [HACKERS] Partitioned tables and relfilenode

> >> I am wondering whether we should deal with inh flat reset in a >> slightly different way. Let expand_inherited_rtentry() mark inh = >> false for the partitioned tables without any partitions and deal with >> those at the time of estimating size by marking those as dummy. That >> might be

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/21 22:21, Ashutosh Bapat wrote: > Some comments about 0003 patch. > > @@ -996,10 +996,20 @@ inheritance_planner(PlannerInfo *root) > Index rti; > + RangeTblEntry *parent_rte; > There's already another variable declared in that function within a loop > foreach(lc,

Re: [HACKERS] Partitioned tables and relfilenode

Some comments about 0003 patch. @@ -996,10 +996,20 @@ inheritance_planner(PlannerInfo *root) Index rti; + RangeTblEntry *parent_rte; There's already another variable declared in that function within a loop foreach(lc, root->append_rel_list) { ... RangeTblEntry

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/19 18:53, Robert Haas wrote: > On Fri, Feb 17, 2017 at 1:12 PM, Amit Langote wrote: >> Do you mean that if database-wide analyze is to be run, we should also >> exclude those RELKIND_RELATION relations that are partitions? >> >> So the only way to update a partition's statistics is to

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/20 5:31, Simon Riggs wrote: > On 16 February 2017 at 11:32, Simon Riggs wrote: >> On 10 February 2017 at 06:19, Amit Langote >> wrote: >> >>> the "right thing" here being that the >>> command's code either throws an error or

Re: [HACKERS] Partitioned tables and relfilenode

On 16 February 2017 at 11:32, Simon Riggs wrote: > On 10 February 2017 at 06:19, Amit Langote > wrote: > >> the "right thing" here being that the >> command's code either throws an error or warning (in some cases) if the >> specified table

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Feb 17, 2017 at 1:12 PM, Amit Langote wrote: >> I agree. But, we need to be careful that a database-wide VACUUM or >> ANALYZE doesn't hit the partitions multiple times, once for the parent >> and again for each child. Actually, a database-wide VACUUM

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/16 23:40, Robert Haas wrote: > On Thu, Feb 16, 2017 at 6:32 AM, Simon Riggs wrote: >> Why not vacuum all partitions? >> Why not analyze all partitions? >> Truncate all partitions > > I agree. But, we need to be careful that a database-wide VACUUM or > ANALYZE

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/15 16:14, Michael Paquier wrote: > On Fri, Feb 10, 2017 at 3:19 PM, Amit Langote > wrote: >> The new partitioned tables do not contain any data by themselves. Any >> data inserted into a partitioned table is routed to and stored in one of >> its

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Feb 16, 2017 at 6:32 AM, Simon Riggs wrote: > Why not vacuum all partitions? > Why not analyze all partitions? > Truncate all partitions I agree. But, we need to be careful that a database-wide VACUUM or ANALYZE doesn't hit the partitions multiple times, once for

Re: [HACKERS] Partitioned tables and relfilenode

On 10 February 2017 at 06:19, Amit Langote wrote: > the "right thing" here being that the > command's code either throws an error or warning (in some cases) if the > specified table is a partitioned table or ignores any partitioned tables > when it reads the list

Re: [HACKERS] Partitioned tables and relfilenode

On Wed, Feb 15, 2017 at 2:14 AM, Michael Paquier wrote: > This is a collection of checks on relkind == RELKIND_PARTITIONED_TABLE > to avoid interactions with partition tables. Did you consider doing > something in the executor instead? That seems inferior, because the

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Feb 10, 2017 at 3:19 PM, Amit Langote wrote: > The new partitioned tables do not contain any data by themselves. Any > data inserted into a partitioned table is routed to and stored in one of > its partitions. In fact, it is impossible to insert *any* data

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/10 15:58, Simon Riggs wrote: > On 10 February 2017 at 06:19, Amit Langote > wrote: >> The new partitioned tables do not contain any data by themselves. Any >> data inserted into a partitioned table is routed to and stored in one of >> its partitions. In

Re: [HACKERS] Partitioned tables and relfilenode

On 10 February 2017 at 06:19, Amit Langote wrote: > The new partitioned tables do not contain any data by themselves. Any > data inserted into a partitioned table is routed to and stored in one of > its partitions. In fact, it is impossible to insert *any* data

[HACKERS] Partitioned tables and relfilenode

The new partitioned tables do not contain any data by themselves. Any data inserted into a partitioned table is routed to and stored in one of its partitions. In fact, it is impossible to insert *any* data before a partition (to be precise, a leaf partition) is created. It seems wasteful then