Re: [HACKERS] moving some partitioning code to executor

On 2017/11/15 2:09, Alvaro Herrera wrote: > Amit Langote wrote: > >> Since that 0001 patch was committed [1], here is the rebased patch. Will >> add this to the November commit-fest. > > Please rebase once more -- 1aba8e651ac3 seems to have broken things > in

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On 2017/11/14 13:00, David Rowley wrote: > On 13 November 2017 at 22:46, Amit Langote wrote: >> On 2017/11/10 12:30, Kyotaro HORIGUCHI wrote: >>> The following uses a bit tricky bitmap operation but >>> is straightforward as a whole. >>> >>>

Re: [HACKERS] moving some partitioning code to executor

On 2017/11/16 0:29, Robert Haas wrote: > On Tue, Nov 14, 2017 at 7:59 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> On 2017/11/15 2:09, Alvaro Herrera wrote: >>> Amit Langote wrote: >>> >>>> Since that 0001 patch was committe

Re: default range partition and constraint exclusion

Horiguchi-san, thanks for the clarifying comment. On 2017/11/27 18:04, Kyotaro HORIGUCHI wrote: > At Fri, 24 Nov 2017 10:49:07 -0500, Robert Haas wrote >> OK, so I am still confused about whether the constraint is wrong or >> the constraint exclusion logic is wrong. One of them, at least, has >>

Re: [HACKERS] INSERT ON CONFLICT and partitioned tables

Thank you Simon for the review. On 2017/11/20 7:33, Simon Riggs wrote: > On 2 August 2017 at 00:56, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > >> The patch's job is simple: > > Patch no longer applies and has some strange behaviours. > >> - Remove th

Re: [HACKERS] UPDATE of partition key

On 2017/11/23 21:57, Amit Khandekar wrote: > If we collect the partition keys in expand_partitioned_rtentry(), we > need to pass the root relation also, so that we can convert the > partition key attributes to root rel descriptor. And the other thing > is, may be, we can check beforehand (in

Re: With commit 4e5fe9ad19, range partition missing handling for the NULL partition key

get_partition_for_tuple now has > a new interface that more clearly separates executor concerns from > generic concerns. > > Amit Langote. A slight comment tweak by me. > > Before above commit insert with NULL partition key in the range partition > was throwi

Re: [HACKERS] UPDATE of partition key

Thanks Amit. Looking at the latest v25 patch. On 2017/11/16 23:50, Amit Khandekar wrote: > Below has the responses for both Amit's and David's comments, starting > with Amit's > On 2 November 2017 at 12:40, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: >>

Re: [HACKERS] path toward faster partition pruning

Hi Jesper. On 2017/11/28 3:30, Jesper Pedersen wrote: > Hi Amit, > > On 11/24/2017 12:00 AM, Amit Langote wrote: >>> On 2017/11/23 3:56, Jesper Pedersen wrote: >>> EXPLAIN (ANALYZE) SELECT t1.a, t1.b, t2.c, t2.d FROM t1 INNER JOIN t2 ON >>> t2.c = t1.b W

Re: Use of uninitialized variables in ExecFindPartition() for parent partition without leaves (HEAD only)

On 2017/11/30 10:11, Amit Langote wrote: > in the attached updated version. Oops, I messed up taking the diff and mistakenly added noise to the patch. Fixed in the attached. Thanks, Amit diff --git a/src/backend/executor/execPartition.c b/src/backend/executor/execPartition.c index 2fc411a

Re: [HACKERS] path toward faster partition pruning

On 2017/11/30 5:28, Robert Haas wrote: > On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> It seems I wrote an Assert in the code to support hash partitioning that >> wasn't based on a valid assumption. I was wrongly assuming tha

Re: [HACKERS] path toward faster partition pruning

On 2017/11/30 11:18, Michael Paquier wrote: > On Thu, Nov 30, 2017 at 10:43 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> I'm working on a revised version of these patches to address recent >> comments by Horiguchi-san. I will also consider the points

Re: [HACKERS] path toward faster partition pruning

On 2017/11/30 7:15, Robert Haas wrote: > On Wed, Nov 29, 2017 at 3:28 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> It seems I wrote an Assert in the code to suppo

Re: Commit fest 2017-11

On 2017/11/30 14:29, Tsunakawa, Takayuki wrote: > From: Michael Paquier [mailto:michael.paqu...@gmail.com] >> All patches not marked as ready for committer have been classified, by either >> being marked as returned with feedback or moved to the next CF. >> I may have made some mistakes of course,

Re: [HACKERS] INSERT ON CONFLICT and partitioned tables

On 2017/12/01 11:27, Simon Riggs wrote: > On 24 November 2017 at 13:45, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: > >>> Why? There is no caller that needs information. >> >> It is to be used if and when ExecInsert() calls >> ExecCheckInd

Re: Use of uninitialized variables in ExecFindPartition() for parent partition without leaves (HEAD only)

On 2017/12/01 11:48, Michael Paquier wrote: > On Thu, Nov 30, 2017 at 10:17 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Oops, I messed up taking the diff and mistakenly added noise to the patch. > > Which is that bit: > - * Build

Re: Isn't partition drop code seriously at risk of deadlock?

On 2017/11/28 9:04, Tom Lane wrote: > The complaint in bug #14927 that heap_drop_with_catalog is not bothering > to check for SearchSysCache lookup failure (in code evidently newly added > for the partition feature) seems to me to be only scratching the surface > of what's wrong with that code.

Re: Use of uninitialized variables in ExecFindPartition() for parent partition without leaves (HEAD only)

Hi Michael. On 2017/11/30 9:07, Michael Paquier wrote: > Hi all, > > Since commit 4e5fe9ad (committer Robert Haas and author Amit Langote), > coverity has been complaining that the new code of ExecFindPartition() > may use a set of values and isnull values which never

Re: default range partition and constraint exclusion

On 2017/11/29 0:52, Robert Haas wrote: > On Mon, Nov 27, 2017 at 4:01 PM, Robert Haas wrote: >> I am out of time for today but will try to look at this some more tomorrow. > > Upon closer study this seems to definitely be a correct fix, so I have > committed it. Apologies

Re: [HACKERS] INSERT ON CONFLICT and partitioned tables

On 2017/12/01 11:01, Amit Langote wrote: > On 2017/12/01 1:02, Robert Haas wrote: >> Second, this would be the first place where the second argument to >> ExecOpenIndices() is passed simply as true. The only other caller >> that doesn't pass constant false is in nodeMo

Re: pg_(total_)relation_size and partitioned tables

Thanks all for your thoughts. I agree with the Robert's point which both David and Michael seem to agree with that we shouldn't really be changing what pg_relation_size() is doing under the covers. And I guess the same for pg_table_size(), too. Both of those functions and their siblings work

Re: [HACKERS] Runtime Partition Pruning

Hi. On 2017/12/16 15:05, David Rowley wrote: > On 13 December 2017 at 00:33, Beena Emerson wrote: >> PFA the updated patch, this can be applied over the v13 patches [1] >> over commit 487a0c1518af2f3ae2d05b7fd23d636d687f28f3 > > Hi Beena, > > Thanks for posting an

Re: [HACKERS] Runtime Partition Pruning

On 2017/12/09 0:57, Robert Haas wrote: > On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson wrote: >> I have added the partition quals that are used for pruning. >> >> PFA the updated patch. I have changed the names of variables to make >> it more appropriate, along with

Re: [HACKERS] UPDATE of partition key

Thanks for the updated patches, Amit. Some review comments. Forgot to remove the description of update_rri and num_update_rri in the header comment of ExecSetupPartitionTupleRouting(). - +extern void pull_child_partition_columns(Relation rel, + Relation parent, +

pg_(total_)relation_size and partitioned tables

Hi. You may have guessed from $subject that the two don't work together. create table p (a int) partition by list (a); create table p1 partition of p for values in (1, 2) partition by list (a); create table p11 partition of p1 for values in (1); create table p12 partition of p1 for values in

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On 2017/12/13 18:48, David Rowley wrote: > On 12 December 2017 at 22:13, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Attached updated patches. > > Thanks for sending the updated patches. > > I don't have a complete review at the

Re: Boolean partitions syntax

Hi Mark, On 2017/12/20 6:46, Mark Dilger wrote: >> On Dec 12, 2017, at 10:32 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> >> wrote: >> Added to CF: https://commitfest.postgresql.org/16/1410/ > > This compiles and passes the regression tests for me. Thanks for

Re: [HACKERS] Add support for tuple routing to foreign partitions

On 2017/12/18 23:25, Alvaro Herrera wrote: > (I wonder why > this function needs a local variable "partition_check" -- seems > pointless). Before 15ce775faa4 [1], there were more than one line where partition_check was being set, but maybe it still didn't have to be a separate variable. Thanks,

non-bulk inserts and tuple routing

Hi. I have a patch that rearranges the code around partition tuple-routing, such that allocation of per-partition objects (ResultRelInfo, TupleConversionMap, etc.) is delayed until a given partition is actually inserted into (i.e., a tuple is routed to it). I can see good win for non-bulk

Re: non-bulk inserts and tuple routing

Hi Ashutosh. On 2017/12/19 19:12, Ashutosh Bapat wrote: > On Tue, Dec 19, 2017 at 3:36 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> >> * Bulk-inserting 100,000 rows using COPY: >> >> copy t1 from '/tmp/t1.csv' csv; >> >> * Ti

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

Hi. On 2017/12/13 9:22, Ali Akbar wrote: > For me, it's better to prevent that from happening. So, attempts to > DROP NOT NULL on the child must be rejected. The attached patch does > that. > > Unfortunately, pg_class has no "has_parent" attribute, so in this > patch, it hits pg_inherits

Re: default range partition and constraint exclusion

On 2017/11/18 8:28, Robert Haas wrote: > On Fri, Nov 17, 2017 at 12:57 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> While working on the patch for partition pruning for declarative >> partitioned tables, I noticed that default range partition will fail to

default range partition and constraint exclusion

Hi. While working on the patch for partition pruning for declarative partitioned tables, I noticed that default range partition will fail to be included in a plan in certain cases due to pruning by constraint exclusion. Consider a multi-column range-partitioned table: create table mc2p (a int,

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On 2017/12/07 19:48, David Rowley wrote: > On 30 November 2017 at 11:15, Robert Haas wrote: >> Committed 0004 after reviewing the code and testing that it seems to >> work as advertised. >> >> 0005 looks like it might need to be split into smaller patches. More

no partition pruning when partitioning using array type

Hi. I noticed that if you partition using a array type column, partition pruning using constraint exclusion fails to work due to a minor problem. Example: create table p (a int[]) partition by list (a); create table p1 partition of p for values in ('{1}'); create table p1 partition of p for

ScalarArrayOpExpr and multi-dimensional arrays

Hi. I wonder if ScalarArrayOpExpr is not really meant for multi-dimensional arrays appearing on the right hand side? Because: # select array[1] = any (array[array[1], array[2]]); ERROR: operator does not exist: integer[] = integer LINE 1: select array[1] = any (array[array[1], array[2]]);

Re: [HACKERS] INSERT ON CONFLICT and partitioned tables

On 2017/12/02 2:57, Robert Haas wrote: > On Fri, Dec 1, 2017 at 2:44 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> I forgot to consider the fact that mtstate could be NULL in >> ExecSetupPartitionTupleRouting(), so would result in dereferencing NULL >

Re: no partition pruning when partitioning using array type

On 2017/12/09 3:46, Robert Haas wrote: > On Fri, Dec 8, 2017 at 5:40 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> I noticed that if you partition using a array type column, partition >> pruning using constraint exclusion fails to work due to a mino

Re: ScalarArrayOpExpr and multi-dimensional arrays

On 2017/12/08 23:34, Tom Lane wrote: > Amit Langote <langote_amit...@lab.ntt.co.jp> writes: >> I wonder if ScalarArrayOpExpr is not really meant for multi-dimensional >> arrays appearing on the right hand side? Because: >> # select array[1] = any (array[array[

Re: Boolean partitions syntax

Hi Dilip. Thanks for the review. On 2017/12/12 15:03, Dilip Kumar wrote: > On Tue, Dec 12, 2017 at 7:19 AM, Amit Langote wrote: >> Horiguchi-san pointed out [1] on a nearby thread that the partitioning >> syntax (the FOR VALUES clause) doesn't accept true and false as valid >

Boolean partitions syntax

Hi. Horiguchi-san pointed out [1] on a nearby thread that the partitioning syntax (the FOR VALUES clause) doesn't accept true and false as valid partition bound datums, which seems to me like an oversight. Attached a patch to fix that. create table bools (a bool) partition by list (a); Before

Re: Boolean partitions syntax

On 2017/12/12 15:35, Amit Langote wrote: > Works for me, updated patch attached. Oops, attached the old one with the last email. Updated one really attached this time. Thanks, Amit From 318c815264b27fcbda5b83e542c6a2970f714399 Mon Sep 17 00:00:00 2001 From: amit <amitlangot...@gmail.com

Re: Boolean partitions syntax

On 2017/12/12 18:12, Ashutosh Bapat wrote: > On Tue, Dec 12, 2017 at 7:19 AM, Amit Langote wrote: >> Horiguchi-san pointed out [1] on a nearby thread that the partitioning >> syntax (the FOR VALUES clause) doesn't accept true and false as valid >> partition bound datums, w

Re: Incorrect comment in get_partition_dispatch_recurse

Hi David. On 2018/05/14 13:57, David Rowley wrote: > I noticed that a comment in get_partition_dispatch_recurse claims that: > > "it contains the > * leaf partition's position in the global list *leaf_part_oids minus 1" > > The "minus 1" part is incorrect. It simply just stores the 0-based >

Re: Needless additional partition check in INSERT?

On 2018/05/11 18:43, Amit Khandekar wrote: > This looks better (it will avoid unnecessary ExecConstraints() call) : > > if (resultRelInfo->ri_PartitionRoot == NULL || > (resultRelInfo->ri_TrigDesc && > resultRelInfo->ri_TrigDesc->trig_insert_before_row)) > check_partition_constr =

Re: \d doesn't show partitioned table foreign keys

On Tue, May 15, 2018 at 12:38 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > On 2018-May-14, Amit Langote wrote: > >> Hi. >> >> I just noticed $subject, which attached seems to fix, although not sure if >> that's the correct fix for the issue. >

Re: Postgres 11 release notes

On 2018/05/15 5:30, Bruce Momjian wrote: > On Sun, May 13, 2018 at 06:53:26PM +0900, Amit Langote wrote: >> The following item >> >> + >> + >> + >> +Have psql \d+ show a partition count of zero (Amit Langote) >> + >&g

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018/05/14 20:29, David Rowley wrote: > On 14 May 2018 at 17:29, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> Hmm, while I agree that simply calling it "0-based index" might be better >> for readers, what's there now doesn't sound incorrect

Re: Indexes on partitioned tables and foreign partitions

On 2018/05/15 2:29, Alvaro Herrera wrote: > On 2018-May-10, Amit Langote wrote: > >> How about we error out even *before* calling DefineIndex for the 1st time? >> I see that ProcessUtilitySlow() gets a list of all partitions when >> locking them for index creation be

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/05/09 13:14, Amit Langote wrote: > Hi David. > > Thanks for addressing my comments. > > On 2018/05/07 15:00, David Rowley wrote: >> v2 patch is attached. > > Looks good to me. Sorry, I should've seen noticed v3 before sending my email. v3 looks good too, b

Re: no partition pruning when partitioning using array type

On 2018/03/01 17:16, Amit Langote wrote: > Added this to CF (actually moved to the September one after first having > added it to the CF that is just getting started). > > It seems to me that we don't need to go with my originally proposed > approach to teach predtest.c to strip Re

Re: Should we add GUCs to allow partition pruning to be disabled?

Hi David. Thanks for addressing my comments. On 2018/05/07 15:00, David Rowley wrote: > v2 patch is attached. Looks good to me. Thanks, Amit

Re: [HACKERS] path toward faster partition pruning

On 2018/05/09 11:31, David Rowley wrote: > On 9 May 2018 at 14:29, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> On 2018/05/09 11:20, Michael Paquier wrote: >>> While looking at this code, is there any reason to not make >>> gen_partprune_steps static?

Re: [HACKERS] path toward faster partition pruning

On 2018/05/09 11:20, Michael Paquier wrote: > While looking at this code, is there any reason to not make > gen_partprune_steps static? This is only used in partprune.c for now, > so the intention is to make it available for future patches? Yeah, making it static might be a good idea. I had

Re: [HACKERS] path toward faster partition pruning

Hi. On 2018/05/09 7:05, Alvaro Herrera wrote: > So I found that this query also crashed (using your rig), > > create table coercepart (a varchar) partition by list (a); > create table coercepart_ab partition of coercepart for values in ('ab'); > create table coercepart_bc partition of coercepart

Re: [Suspect SPAM] Re: [HACKERS] path toward faster partition pruning

Thank you Marina for the report and Michael for following up. On 2018/05/07 16:56, Michael Paquier wrote: > On Mon, May 07, 2018 at 10:37:10AM +0900, Michael Paquier wrote: >> On Fri, May 04, 2018 at 12:32:23PM +0300, Marina Polyakova wrote: >>> I got a similar server crash as in [1] on the

Re: [HACKERS] path toward faster partition pruning

On 2018/05/09 22:43, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2018/05/09 11:31, David Rowley wrote: >>> On 9 May 2018 at 14:29, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >>>> On 2018/05/09 11:20, Michael Paquier wrote: >>>>&

Re: Indexes on partitioned tables and foreign partitions

On 2018/05/09 23:57, Robert Haas wrote: > For right now, I think the options are (1) throw an ERROR if we > encounter a foreign table or (2) silently skip the foreign table. I > think (2) is defensible for non-UNIQUE indexes, because the index is > just a performance optimization. Along with

Re: Indexes on partitioned tables and foreign partitions

On 2018/05/10 10:37, Michael Paquier wrote: > On Thu, May 10, 2018 at 10:15:05AM +0900, Amit Langote wrote: >> While I agree with this, let me point out that we do allow inherited check >> constraints on foreign tables that are not actually enforced locally. >> >> creat

Re: Needless additional partition check in INSERT?

On 2018/05/10 14:42, Simon Riggs wrote: > On 10 May 2018 at 05:33, David Rowley <david.row...@2ndquadrant.com> wrote: >> On 10 May 2018 at 16:13, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >>> The patch to ExecInsert looks good, but I think we also

Re: Needless additional partition check in INSERT?

On 2018/05/10 13:33, David Rowley wrote: > On 10 May 2018 at 16:13, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> The patch to ExecInsert looks good, but I think we also need to do the >> same thing in CopyFrom. > > I think so too. > > Updated pa

Re: Needless additional partition check in INSERT?

On 2018/05/10 12:55, David Rowley wrote: > Hi, > > Scanning ExecInsert, it looks like there's a needless additional > partition constraint check against the tuple. This should only be > required if there's a before row INSERT trigger. The code block up > one from the additional check tries to

Re: Indexes on partitioned tables and foreign partitions

On 2018/05/10 10:02, Michael Paquier wrote: > Something > that I find confusing on HEAD though is that DefineIndex calls itself > around line 1006 and cascades through each children but there is no > context about the error. > > For example if I have this partition layer: > CREATE TABLE

Re: Postgres 11 release notes

11.html Thank you for compiling this, Bruce! > I expect a torrent of feedback. ;-) The following item + + + +Have psql \d+ show a partition count of zero (Amit Langote) + missed mentioning Ashutosh Bapat as an author. Maybe, the item name and description text could b

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

On 2018/05/11 21:48, Etsuro Fujita wrote: > (2018/05/11 16:19), Amit Langote wrote: >> On 2018/05/11 16:12, Amit Langote wrote: >>> Just to clarify, does this problem only arise because there is a pushed >>> down join involving the child? That is,

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/05/14 9:55, David Rowley wrote: > On 13 May 2018 at 03:30, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >> Amit Langote wrote: >> >>> +1 to this more radical overhaul of this part of the documentation. >> >> Thanks. I pushed now after s

\d doesn't show partitioned table foreign keys

Hi. I just noticed $subject, which attached seems to fix, although not sure if that's the correct fix for the issue. create table foo (a int primary key); create table doo (a int primary key); create table bar (a int references foo references doo) partition by list (a); create table bar1

Re: \d doesn't show partitioned table foreign keys

On 2018/05/14 11:50, Amit Langote wrote: > Hi. > > I just noticed $subject, which attached seems to fix, although not sure if > that's the correct fix for the issue. I updated the comment above the changed code to explain things as I see them. Attached updated patch. Thanks, Ami

Re: Needless additional partition check in INSERT?

Hi David. On 2018/05/10 18:56, David Rowley wrote: > On 10 May 2018 at 17:42, Simon Riggs wrote: >> Patch is good. >> >> The cause of this oversight is the lack of comments to explain the >> original coding, so we need to correct that in this patch, please. > > Thanks for

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

Fujita-san, On 2018/05/10 21:41, Etsuro Fujita wrote: > I think the reason for that is: in that case we try to find the target > foreign-join RelOptInfo using find_join_rel in postgresPlanDirectModify, > but can't find it, because the given root is the *parent* root and > doesn't have join

Re: Needless additional partition check in INSERT?

On 2018/05/11 15:27, Michael Paquier wrote: > That's really up to the patch > author at the end (I prefer matching with NULL, but usually it is better > to comply with the surroundings for consistency). Yeah. I think in this case I'll have to withdraw my comment because most places that check

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/05/11 2:13, Robert Haas wrote: > On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera > wrote: >> David G. Johnston wrote: >>> As a user I don't really need to know which model is implemented and the >>> name doesn't necessarily imply the implementation. Pruning

Re: Should we add GUCs to allow partition pruning to be disabled?

Hi. On 2018/05/11 4:45, Alvaro Herrera wrote: > I'm thinking something like this. +1 to this more radical overhaul of this part of the documentation. > The examples for runtime pruning are lame -- in the first, the text says > "watch out for Subplans Removed" and then the example provided

Re: Needless additional partition check in INSERT?

On 2018/05/11 15:12, David Rowley wrote: > Thanks for looking > > On 11 May 2018 at 17:48, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> By the way, >> >> +!resultRelInfo->ri_PartitionRoot) >> >> This should be resultRelI

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

On 2018/05/11 16:12, Amit Langote wrote: > Just to clarify, does this problem only arise because there is a pushed > down join involving the child? That is, does the problem only occur as of > the following commit: > > commit 1bc0100d270e5bcc980a0629b8726a32a497e788 > Autho

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018/05/17 23:24, Robert Haas wrote: > On Thu, May 17, 2018 at 12:04 AM, David Rowley wrote: >> I'm not really a fan of overloading properties with a bunch of text. >> Multiple int or text properties would be easier to deal with, >> especially so when you consider the other explain formats.

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

Fujita-san, On 2018/05/17 21:51, Etsuro Fujita wrote: > (2018/05/17 14:19), Amit Langote wrote: >> Looking at this for a bit, I wondered if this crash wouldn't have occurred >> if the "propagation" had also considered join relations in addition to >> simple relati

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

Fujita-san, On 2018/05/16 18:35, Etsuro Fujita wrote: > (2018/05/14 9:45), Amit Langote wrote: >> On 2018/05/11 21:48, Etsuro Fujita wrote: >>> (2018/05/11 16:19), Amit Langote wrote: >>>> On 2018/05/11 16:12, Amit Langote wrote: >>>>> Just to

Re: Should we add GUCs to allow partition pruning to be disabled?

On Sat, May 19, 2018 at 5:02 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, May 18, 2018 at 4:22 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Yeah, I think it'd help to have Append be annotated as suggested by Robert >> above. I guess if

Re: Incorrect comment in get_partition_dispatch_recurse

On Thu, May 17, 2018 at 10:29 PM, Robert Haas wrote: > Unless the indexing system actually can't reference the first element > of *pds, and -1 means the second element. But then I think we need a > more verbose explanation here. First element in *pds list (and the array

Re: Postgres 11 release notes

On Mon, May 21, 2018 at 4:34 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 19 May 2018 at 03:58, Amit Langote <amitlangot...@gmail.com> wrote: >> I wonder what you think about including this little performance item: >> >> https://www.postgre

Re: [Sender Address Forgery]Re: Postgres 11 release notes

On 2018/05/23 10:16, Bruce Momjian wrote: > On Sat, May 19, 2018 at 12:58:04AM +0900, Amit Langote wrote: >> Hi Bruce. >> >> On Tue, May 15, 2018 at 12:46 PM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> On 2018/05/15 5:30, Bruce Momjian wrot

Re: Postgres 11 release notes

On 2018/05/23 10:36, Bruce Momjian wrote: > On Wed, May 23, 2018 at 10:28:41AM +0900, Amit Langote wrote: >>> Uh, we already have this in the release notes: >>> >>> Allow faster partition elimination during query processing (Amit >>>

Re: documentation fixes for partition pruning, round two

Hi Justin. Thanks for writing the patch. I have a couple of comments. On 2018/05/24 8:31, Justin Pryzby wrote: > On Thu, May 24, 2018 at 10:46:38AM +1200, David Rowley wrote: >> On 24 May 2018 at 09:35, Justin Pryzby wrote: >>> On Fri, May 18, 2018 at 08:56:53PM -0500,

Re: Performance regression with PostgreSQL 11 and partitioning

On Fri, May 25, 2018 at 11:49 PM, Robert Haas wrote: > On Fri, May 25, 2018 at 10:30 AM, Thomas Reiss > wrote: >> Then I used the following to compare the planning time : >> explain (analyze) SELECT * FROM t1 WHERE dt = '2018-05-25'; >> >> With

Re: Postgres 11 release notes

Hi Bruce. On Tue, May 15, 2018 at 12:46 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2018/05/15 5:30, Bruce Momjian wrote: >> I like it, done. > > Thank you. I wonder what you think about including this little performance item: https://www.postgresql.o

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018/05/18 6:14, David Rowley wrote: > On 18 May 2018 at 02:13, Tom Lane wrote: >> Maybe what you need is a redesign. This convention seems impossibly >> confusing and hence error-prone. What about using a separate bool to >> indicate which list the index refers to? > >

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018/05/18 5:56, David Rowley wrote: > On 18 May 2018 at 06:21, Robert Haas wrote: >> All right, so let's just say that explicitly. Maybe something like >> the attached. > > That looks fine to me. Me too, except: +* *pds list is the root partition, so 0

Re: partition -> partitioned

On 2018/05/17 11:40, David Rowley wrote: > On 17 May 2018 at 13:52, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> Commit 499be013de6 used 'partition' where it really meant 'partitioned' in >> a few places including in a variable name. For example, what almo

partition -> partitioned

Hi. Commit 499be013de6 used 'partition' where it really meant 'partitioned' in a few places including in a variable name. For example, what almost all places call 'partitioned_rels', make_partition_pruneinfo called 'partition_rels'. Attached a patch to make that uniform to avoid confusion.

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018/05/17 3:28, David Rowley wrote: > On 17 May 2018 at 02:51, Robert Haas wrote: >> I think that's clearer. Committed with a few tweaks that are >> hopefully improvements. > > Thanks for committing. Although, I disagree with your tweak: > > +* 1-based index into

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

On 2018/05/17 12:30, Etsuro Fujita wrote: > (2018/05/17 1:16), Robert Haas wrote: >> Was it just good luck that this ever worked at all?  I mean: >> >> -    if (rti<  root->simple_rel_array_size&& >> -    root->simple_rel_array[rti] != NULL) >> +    if (rti< 

Re: Needless additional partition check in INSERT?

On 2018/05/17 14:15, David Rowley wrote: > On 10 May 2018 at 21:56, David Rowley wrote: >> On 10 May 2018 at 17:42, Simon Riggs wrote: >>> Patch is good. >>> >>> The cause of this oversight is the lack of comments to explain the >>> original

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

On 2018/05/17 14:19, Amit Langote wrote: > Looking at this for a bit, I wondered if this crash wouldn't have occurred > if the "propagation" had also considered join relations in addition to > simple relations. For example, if I changed inheritance_planner like the > a

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/12 22:22, Ashutosh Bapat wrote: > -- create triggers, user may create different trigger functions one > for each partition, unless s/he understands that the tables can share > trigger functions > create function trig_t1p1() returns trigger as $$ begin return new; > end;$$ language

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

Hi. On 2018/06/19 1:59, Alvaro Herrera wrote: > What does worry me a little bit now, reading this discussion, is whether > we've made the triggers in partitions visible enough. We'll have this > problem once we implement BEFORE ROW triggers as proposed, and I think > we already have this problem

Re: Partitioning with temp tables is broken

Hello. On 2018/06/18 15:02, Michael Paquier wrote: > On Mon, Jun 18, 2018 at 01:27:51PM +0900, Amit Langote wrote: >> On 2018/06/17 22:11, Michael Paquier wrote: >> Which checks do you think are missing other than those added by the >> proposed patch? > > I was just

Re: Needless additional partition check in INSERT?

On 2018/06/12 10:37, David Rowley wrote: > On 12 June 2018 at 09:13, Alvaro Herrera wrote: >> Hearing no complaints I pushed it with the proposed shape. > > Thanks for working on it and pushing. Thank you David and Alvaro. I think the last solution involving calling ExecPartitionCheck directly

Re: Server crashed with dense_rank on partition table.

Hi. On 2018/06/13 14:55, Michael Paquier wrote: > On Wed, Jun 13, 2018 at 11:08:38AM +0530, Rajkumar Raghuwanshi wrote: >> postgres=# SELECT dense_rank(b) WITHIN GROUP (ORDER BY a) FROM pagg_tab >> GROUP BY b ORDER BY 1; >> server closed the connection unexpectedly >> This probably means the

Re: Partitioning with temp tables is broken

On 2018/06/14 11:09, Michael Paquier wrote: > On Wed, Jun 13, 2018 at 10:25:23PM +0530, amul sul wrote: >> On Wed, Jun 13, 2018, 8:34 PM Tom Lane wrote: >>> Even if you want to argue that there's a use case for these situations, >>> it seems far too late in the release cycle to be trying to fix

  1   2   3   4   5   6   7   8   9   10   >