Re: Problem with default partition pruning

On Wed, Aug 14, 2019 at 12:25 AM Alvaro Herrera wrote: > On 2019-Aug-13, Amit Langote wrote: > > > Thanks a lot for revising. Looks neat, except: > > > > + * This is a measure of last resort only to be used because the default > > + * partition cannot be pruned using the steps; regular pr

Re: Problem with default partition pruning

On 2019-Aug-13, Amit Langote wrote: > Thanks a lot for revising. Looks neat, except: > > + * This is a measure of last resort only to be used because the default > + * partition cannot be pruned using the steps; regular pruning, which is > + * cheaper, is sufficient when no default p

Re: Problem with default partition pruning

Hi Alvaro, On Tue, Aug 13, 2019 at 2:45 AM Alvaro Herrera wrote: > v3-0001 still seems to leave things a bit duplicative. I think we can > make it better if we move the logic to set RelOptInfo->partition_qual to > a separate routine (set_baserel_partition_constraint mirroring the > existing set_

Re: Problem with default partition pruning

On Mon, 12 Aug 2019 at 18:45, Alvaro Herrera wrote: > I think that should appease > Simon's performance concern for the most common case of default > partition not existing. > Much appreciated, thank you. -- Simon Riggshttp://www.2ndQuadrant.com/ P

Re: Problem with default partition pruning

v3-0001 still seems to leave things a bit duplicative. I think we can make it better if we move the logic to set RelOptInfo->partition_qual to a separate routine (set_baserel_partition_constraint mirroring the existing set_baserel_partition_key_exprs), and then call that from both places that need

Re: Problem with default partition pruning

On 2019-Aug-09, Amit Langote wrote: > Hmm, oops. I think that judgement was a bit too rushed on my part. I > unintentionally ended up making the partition constraint to *always* > be fetched, whereas we don't need it in most cases. I've reverted > that change. Yeah, I was quite confused about

Re: Problem with default partition pruning

Thanks for the comments. On Fri, Aug 9, 2019 at 2:44 PM Kyotaro Horiguchi wrote: > +++ b/src/backend/optimizer/util/plancat.c > @@ -1267,10 +1267,14 @@ get_relation_constraints(PlannerInfo *root, > */ >if (include_partition && relation->rd_rel->relispartition) >{ > ... > +else >

Re: Problem with default partition pruning

At Fri, 9 Aug 2019 14:02:36 +0900, Amit Langote wrote in > On Fri, Aug 9, 2019 at 1:17 PM Amit Langote wrote: > > On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi > > wrote: > > > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote: > > > > When working on it, I realized > > > > that the wa

Re: Problem with default partition pruning

On Fri, Aug 9, 2019 at 1:17 PM Amit Langote wrote: > On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi > wrote: > > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote: > > > When working on it, I realized > > > that the way RelOptInfo.partition_qual is processed is a bit > > > duplicative, so

Re: Problem with default partition pruning

Horiguchi-san, Thanks for the review. On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi wrote: > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote: > > When working on it, I realized > > that the way RelOptInfo.partition_qual is processed is a bit > > duplicative, so I created a separate pat

Re: Problem with default partition pruning

Sorry for being late. I found it is committed before I caught up this thread again.. At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote in > Hi Alvaro, > > On Thu, Aug 8, 2019 at 5:27 AM Alvaro Herrera > wrote: > > On 2019-Aug-07, Simon Riggs wrote: > > > I saw your recent commit and it s

Re: Problem with default partition pruning

Hello, On Thu, Aug 8, 2019 at 5:09 PM Amit Langote wrote: > > Hi Simon, > > On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs wrote: > > On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera > > wrote: > >> Well, yes, avoiding that is the point of this commit also: we were > >> scanning some partitions for som

Re: Problem with default partition pruning

Hi Simon, On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs wrote: > On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera wrote: >> Well, yes, avoiding that is the point of this commit also: we were >> scanning some partitions for some queries, after this patch we're >> supposed not to. > > > Understood > > My

Re: Problem with default partition pruning

On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera wrote: > On 2019-Aug-07, Simon Riggs wrote: > > > I saw your recent commit and it scares me in various places, noted below. > > > > "Commit: Apply constraint exclusion more generally in partitioning" > > > > "This applies particularly to the default par

Re: Problem with default partition pruning

Hi Hosoya-san, I am sorry for so late to reply to you. I merged the patches into master(commit:  44460d7017cde005d7a2e246db0b32375bfec15d). I tested the case I used in the previous patches and didn't find any issues.  Now I find that you are rethinking some of the details. I will cont

Re: Problem with default partition pruning

Hi Alvaro, On Thu, Aug 8, 2019 at 5:27 AM Alvaro Herrera wrote: > On 2019-Aug-07, Simon Riggs wrote: > > I saw your recent commit and it scares me in various places, noted below. > > > > "Commit: Apply constraint exclusion more generally in partitioning" > > > > "This applies particularly to the

Re: Problem with default partition pruning

On 2019-Aug-07, Simon Riggs wrote: > I saw your recent commit and it scares me in various places, noted below. > > "Commit: Apply constraint exclusion more generally in partitioning" > > "This applies particularly to the default partition..." > > My understanding of the thread was the complaint

Re: Problem with default partition pruning

On Tue, 6 Aug 2019 at 23:18, Alvaro Herrera wrote: > On 2019-Aug-06, Alvaro Herrera wrote: > > > Well, if this is really all that duplicative, one thing we could do is > > run this check in get_partprune_steps_internal only if > > constraint_exclusion is a value other than on; we should achieve t

Re: Problem with default partition pruning

On Wed, Aug 7, 2019 at 3:30 PM yuzuko wrote: > > In short, I propose to get this done as the patch I posted in > > https://postgr.es/m/20190806133053.GA23706@alvherre.pgsql > > > I agree with your proposal. Also, I confirmed a default partition was pruned > as expected with your patch. +1. Than

Re: Problem with default partition pruning

Hello, > > Well, if this is really all that duplicative, one thing we could do is > > run this check in get_partprune_steps_internal only if > > constraint_exclusion is a value other than on; we should achieve the > > same effect with no repetition. Patch for that is attached. However, > > if I

Re: Problem with default partition pruning

On 2019-Aug-06, Alvaro Herrera wrote: > Well, if this is really all that duplicative, one thing we could do is > run this check in get_partprune_steps_internal only if > constraint_exclusion is a value other than on; we should achieve the > same effect with no repetition. Patch for that is attach

Re: Problem with default partition pruning

Hello, On 2019-Aug-06, Amit Langote wrote: > On Mon, Aug 5, 2019 at 11:39 PM Alvaro Herrera > wrote: > > I don't think that we care about what happens with constraint_exclusion > > is on. That's not the recommended value for that setting anyway. > > One issue I expressed with unconditionally

Re: Problem with default partition pruning

On 2019-Aug-05, Alvaro Herrera wrote: > So we have three locations for that test; one is where it currently is, > which handles a small subset of the cases. The other is where Amit > first proposed putting it, which handles some additional cases; and the > third one is where your latest patch put

Re: Problem with default partition pruning

Hi Alvaro, On Mon, Aug 5, 2019 at 11:39 PM Alvaro Herrera wrote: > On 2019-Aug-05, yuzuko wrote: > > > So I proposed moving the if() block to the current place. > > The latest patch can solve both queries but I found the latter > > problem can be solved by setting constraint_exclusion = on. > > S

Re: Problem with default partition pruning

On 2019-Aug-05, yuzuko wrote: > So I proposed moving the if() block to the current place. > The latest patch can solve both queries but I found the latter > problem can be solved by setting constraint_exclusion = on. So we have three locations for that test; one is where it currently is, which ha

Re: Problem with default partition pruning

On 2019-Aug-05, yuzuko wrote: > However, I'm still concerned that the block > - > ... > - > is written in the right place as Amit explained [1]. Yeah, I have that patch installed locally and I'm looking about it. Thanks for the reminder. I also have an eye on Horiguchi's patch elsewhere

Re: Problem with default partition pruning

Hi Alvaro, Thanks for reviewing. The modification you made seems correct to me. However, I'm still concerned that the block - if (partconstr) { partconstr = (List *) expression_planner((Expr *) partconstr); if (context->rel->relid != 1)

Re: Problem with default partition pruning

Hi Alvaro and Amit, Thanks for reviewing and fixing the patch. Also, I confirmed the commit message explained the modification clearly. Thanks a lot. Yuzuko Hosoya On Mon, Aug 5, 2019 at 12:24 AM Alvaro Herrera wrote: > > On 2019-Aug-04, Alvaro Herrera wrote: > > > So this is the best commit

Re: Problem with default partition pruning

I propose the comment rewordings as attached. Mostly, this updates the comment atop the function to cover the case being modified, and then the new comment just refers to the new explicitly stated policy, so it bcomes simpler. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ Postgre

Re: Problem with default partition pruning

Hi Alvaro, On Mon, Aug 5, 2019 at 12:24 AM Alvaro Herrera wrote: > > On 2019-Aug-04, Alvaro Herrera wrote: > > > So this is the best commit messages I could come up with at this stupid > > hour. I think the wording is pretty poor but at least it seems correct. > > I'm not sure I'll be able to ge

Re: Problem with default partition pruning

On 2019-Aug-04, Alvaro Herrera wrote: > So this is the best commit messages I could come up with at this stupid > hour. I think the wording is pretty poor but at least it seems correct. > I'm not sure I'll be able to get this pushed tomorrow, but I'll try. Pushed. Since this is Sunday before mi

Re: Problem with default partition pruning

So this is the best commit messages I could come up with at this stupid hour. I think the wording is pretty poor but at least it seems correct. I'm not sure I'll be able to get this pushed tomorrow, but I'll try. Improve pruning of a default partition When querying a partitioned table contai

Re: Problem with default partition pruning

On 2019-Jul-03, Amit Langote wrote: > Hosoya-san, > > Thanks for updating the patches. > > I have no comment in particular about > v4_default_partition_pruning.patch, Cool, thanks. I spent some time reviewing this patch (the first one) and I propose the attached cosmetic changes. Mostly they

Re: Problem with default partition pruning

On Wed, Jul 31, 2019 at 9:49 PM Alvaro Herrera wrote: > On 2019-Jul-31, Amit Langote wrote: > > I noticed that the patch is still marked as "Waiting on Author" ever > > since Shawn set it that way on June 17. Since Hosoya-san posted > > updated patches on June 27, the status should've been change

Re: Problem with default partition pruning

On 2019-Jul-31, Amit Langote wrote: > Hello, > > I noticed that the patch is still marked as "Waiting on Author" ever > since Shawn set it that way on June 17. Since Hosoya-san posted > updated patches on June 27, the status should've been changed to > "Needs Review". Or maybe "Ready for Commit

Re: Problem with default partition pruning

Hello, I noticed that the patch is still marked as "Waiting on Author" ever since Shawn set it that way on June 17. Since Hosoya-san posted updated patches on June 27, the status should've been changed to "Needs Review". Or maybe "Ready for Committer", because the last time I looked, at least th

Re: Problem with default partition pruning

Hosoya-san, Thanks for updating the patches. I have no comment in particular about v4_default_partition_pruning.patch, but let me reiterate my position about v5_ignore_contradictory_where_clauses_at_partprune_step.patch, which I first stated in the following email a few months ago: https://www.p

Re: Problem with default partition pruning

Hello, On Tue, Jun 25, 2019 at 1:45 PM yuzuko wrote: > > Hello Shawn, Alvaro, > > Thank you for testing patches and comments. > Yes, there are two patches: > (1) v4_default_partition_pruning.patch fixes problems with default > partition pruning > and (2) v3_ignore_contradictory_where_clauses_at_p

Re: Problem with default partition pruning

Hello Shawn, Alvaro, Thank you for testing patches and comments. Yes, there are two patches: (1) v4_default_partition_pruning.patch fixes problems with default partition pruning and (2) v3_ignore_contradictory_where_clauses_at_partprune_step.patch determines if a given clause contradicts a sub-par

Re: Problem with default partition pruning

On 2019-Jun-24, shawn wang wrote: Hello, > Thank you for your reply. > You can see that the mail start time is February 22. So I looked at the > latest version at that time. I found that v11.2 was the newest branch at > the time. So I tried to merge this patch into the code, and I found that > ev

Re: Problem with default partition pruning

Hi Alvaro, Thank you for your reply. You can see that the mail start time is February 22. So I looked at the latest version at that time. I found that v11.2 was the newest branch at the time. So I tried to merge this patch into the code, and I found that everything worked. So I tested on this branc

Re: Problem with default partition pruning

On 2019-Jun-17, Shawn Wang wrote: > I tested different types of key values, and multi-level partitioned tables, > and found no problems. > Only the SQL in the file of src/test/regress/results/partition_prune.out has > a space that caused the regression test to fail. It's not clear to me what pa

Re: Problem with default partition pruning

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hi Hosoya-san, I tested different types of key values, and multi-leve

Re: Problem with default partition pruning

At Wed, 10 Apr 2019 14:55:48 +0900, Amit Langote wrote in > On 2019/04/10 12:53, Kyotaro HORIGUCHI wrote: > > At Wed, 10 Apr 2019 11:17:53 +0900, Amit Langote > > wrote: > >> Yeah, I think we should move the "if (partconstr)" block to the "if > >> (is_orclause(clause))" block as I originally

Re: Problem with default partition pruning

On 2019/04/10 14:55, Amit Langote wrote: > 2. Hosoya-san reported on 2019/03/22 that a contradictory WHERE clause > applied to a *partition* doesn't return an empty plan: > >> I understood Amit's proposal. But I think the issue Thibaut reported >> would occur regardless of whether clauses have O

Re: Problem with default partition pruning

On 2019/04/10 12:53, Kyotaro HORIGUCHI wrote: > At Wed, 10 Apr 2019 11:17:53 +0900, Amit Langote > wrote: >> Yeah, I think we should move the "if (partconstr)" block to the "if >> (is_orclause(clause))" block as I originally proposed in: >> >> https://www.postgresql.org/message-id/9bb31dfe-b0d0-5

Re: Problem with default partition pruning

Hi. (The thread seems broken for Thunderbird) At Wed, 10 Apr 2019 11:24:11 +0900, "Yuzuko Hosoya" wrote in <00df01d4ef44$7bb79370$7326ba50$@lab.ntt.co.jp> > > Why? If clauses contains a clause on a partition key, the clause is > > involved in determination of whether a partition survives or n

Re: Problem with default partition pruning

At Wed, 10 Apr 2019 11:17:53 +0900, Amit Langote wrote in <494124a7-d305-1bc9-ef64-d5c790e13...@lab.ntt.co.jp> > On 2019/04/09 17:37, Kyotaro HORIGUCHI wrote: > > At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" > > wrote > >>> So still it is wrong that the new code is added at the beginning

Re: Problem with default partition pruning

Hi, Amit. At Wed, 10 Apr 2019 10:48:38 +0900, Amit Langote wrote in <4ef8d47d-b0c7-3093-5aaa-226162c5b...@lab.ntt.co.jp> > > I think this is useful even counting possible degradation, and I > > believe generate_partition_qual is not called so often. > > I think more commonly used forms of sub-

Re: Problem with default partition pruning

fujitsu.com; pgsql-hackers@lists.postgresql.org > Subject: Re: Problem with default partition pruning > > Hi. > > At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" > wrote in > <00cf01d4eea7$afa43370$0eec9a50$@lab.ntt.co.jp> > > > So still it is wrong t

Re: Problem with default partition pruning

On 2019/04/09 17:37, Kyotaro HORIGUCHI wrote: > At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" > wrote >>> So still it is wrong that the new code is added at the beginning of the >>> loop on clauses in >>> gen_partprune_steps_internal. >>> If partqual resul

Re: Problem with default partition pruning

Horiguchi-san, On 2019/04/09 18:49, Kyotaro HORIGUCHI wrote: > Hi, Amit. Thank you for the explanation. > > At Tue, 9 Apr 2019 18:09:20 +0900, Amit Langote > wrote in > <4c1074cc-bf60-1610-c728-9a5b12f5b...@lab.ntt.co.jp> >>> The partition constraint is equivalent to "(a IS NOT NULL) AND (a >>

Re: Problem with default partition pruning

Hi, Amit. Thank you for the explanation. At Tue, 9 Apr 2019 18:09:20 +0900, Amit Langote wrote in <4c1074cc-bf60-1610-c728-9a5b12f5b...@lab.ntt.co.jp> > > The partition constraint is equivalent to "(a IS NOT NULL) AND (a > >> = 2) AND (a < 4)". Is it intentional (for, for example, > > performanc

Re: Problem with default partition pruning

Horiguchi-san, On 2019/04/09 17:51, Kyotaro HORIGUCHI wrote: > At Tue, 09 Apr 2019 17:37:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20190409.173725.31175835.horiguchi.kyot...@lab.ntt.co.jp> >>> I'm attaching the latest version. Could you please check it again? > > By the

Re: Problem with default partition pruning

At Tue, 09 Apr 2019 17:37:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190409.173725.31175835.horiguchi.kyot...@lab.ntt.co.jp> > > I'm attaching the latest version. Could you please check it again? By the way, I noticed that partition constraint in a multi-level partition cont

Re: Problem with default partition pruning

Hi. At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" wrote in <00cf01d4eea7$afa43370$0eec9a50$@lab.ntt.co.jp> > > So still it is wrong that the new code is added at the beginning of the > > loop on clauses in > > gen_partprune_steps_internal. > > > > > If partq

RE: Problem with default partition pruning

> imai.yoshik...@jp.fujitsu.com; > pgsql-hackers@lists.postgresql.org > Subject: Re: Problem with default partition pruning > > Sigh.. > > At Tue, 09 Apr 2019 10:28:48 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20190409.102848.252476604.horiguchi.kyo

Re: Problem with default partition pruning

Sigh.. At Tue, 09 Apr 2019 10:28:48 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190409.102848.252476604.horiguchi.kyot...@lab.ntt.co.jp> > As the second thought. Partition constraint is not constraint > expression so that's fair to apply partqual ignoring > constraint_exclusion.

Re: Problem with default partition pruning

At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" wrote in <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > BTW, now I'm a bit puzzled between whether this case should be fixed by > > hacking on partprune.c like > > this patch does or whether to work on getting the other patch committed and

Re: Problem with default partition pruning

At Mon, 08 Apr 2019 20:42:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190408.204251.143128146.horiguchi.kyot...@lab.ntt.co.jp> > At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" > wrote in > <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > > BTW, now I'm a bit puzzled b

Re: Problem with default partition pruning

At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" wrote in <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > BTW, now I'm a bit puzzled between whether this case should be fixed by > > hacking on partprune.c like > > this patch does or whether to work on getting the other patch committed and

RE: Problem with default partition pruning

Amit-san, > -Original Message- > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Friday, April 05, 2019 6:47 PM > To: Yuzuko Hosoya ; 'Thibaut' > ; 'Imai, > Yoshikazu' > Cc: 'PostgreSQL Hackers' > Subject: Re:

Re: Problem with default partition pruning

Hosoya-san, On 2019/04/04 13:00, Yuzuko Hosoya wrote: > I added some test cases to each patch according to tests > discussed in this thread. Thanks a lot. > However, I found another problem as follows. This query should > output "One-Time Filter: false" because rlp3's constraints > contradic

RE: Problem with default partition pruning

Amit-san, Thanks for the comments. > > Thanks for dividing patches that way. > > Would it be a good idea to add some new test cases to these patches, just so > it's easily apparent what > we're changing? Yes, I agree with you. > > So, we could add the test case presented by Thibaut at the fo

Re: Problem with default partition pruning

Hosoya-san, On 2019/04/02 14:02, Yuzuko Hosoya wrote: > Hi, > >> Maybe we should have two patches as we seem to be improving two things: >> >> 1. Patch to fix problems with default partition pruning originally reported >> by Hosoya-san >> >> 2. Patch to determine if a given clause contradicts a

RE: Problem with default partition pruning

Hi, > Maybe we should have two patches as we seem to be improving two things: > > 1. Patch to fix problems with default partition pruning originally reported > by Hosoya-san > > 2. Patch to determine if a given clause contradicts a sub-partitioned table's > partition constraint, > fixing probl

RE: Problem with default partition pruning

Hi, > > Hi, > > On 2019/03/23 2:36, Thibaut Madelaine wrote: > > I tested your last patch and if I didn't mix up patches on the end of > > a too long week, I get a problem when querying the sub-sub partition: > > > > test=# explain select * from test2_0_10 where id = 25; > >

Re: Problem with default partition pruning

Hi, On 2019/03/23 2:36, Thibaut Madelaine wrote: > I tested your last patch and if I didn't mix up patches on the end of a > too long week, I get a problem when querying the sub-sub partition: > > test=# explain select * from test2_0_10 where id = 25; > QUERY PLAN

Re: Problem with default partition pruning

Le 22/03/2019 à 07:38, Amit Langote a écrit : > Hosoya-san, > > On 2019/03/22 15:02, Yuzuko Hosoya wrote: >> I understood Amit's proposal. But I think the issue Thibaut reported would >> occur regardless of whether clauses have OR clauses or not as follows. >> I tested a query which should outp

Re: Problem with default partition pruning

Hosoya-san, On 2019/03/22 15:02, Yuzuko Hosoya wrote: > I understood Amit's proposal. But I think the issue Thibaut reported would > occur regardless of whether clauses have OR clauses or not as follows. > I tested a query which should output "One-Time Filter: false". > > # explain select * fro

RE: Problem with default partition pruning

Hi, Thanks a lot for additional tests and the new patch. > Le 20/03/2019 à 10:06, Amit Langote a écrit : > > Hi Thibaut, > > > > On 2019/03/19 23:58, Thibaut Madelaine wrote: > >> I kept on testing with sub-partitioning. > > Thanks. > > > >> I found a case, using 2 default partitions, where a de

Re: Problem with default partition pruning

Le 20/03/2019 à 10:06, Amit Langote a écrit : > Hi Thibaut, > > On 2019/03/19 23:58, Thibaut Madelaine wrote: >> I kept on testing with sub-partitioning. > Thanks. > >> I found a case, using 2 default partitions, where a default partition is >> not pruned: >> >> -- >> >> create table

Re: Problem with default partition pruning

Hi Thibaut, On 2019/03/19 23:58, Thibaut Madelaine wrote: > I kept on testing with sub-partitioning. Thanks. > I found a case, using 2 default partitions, where a default partition is > not pruned: > > -- > > create table test2(id int, val text) partition by range (id); > create tab

Re: Problem with default partition pruning

Le 19/03/2019 à 08:01, Yuzuko Hosoya a écrit : > Hi Amit-san, > > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Monday, March 18, 2019 6:44 PM > >> Hosoya-san, >> >> On 2019/03/15 15:05, Yuzuko Hosoya wrote: >>> Indeed, it's problematic. I also did test and I found that thi

RE: Problem with default partition pruning

Hi Amit-san, From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] Sent: Monday, March 18, 2019 6:44 PM > Hosoya-san, > > On 2019/03/15 15:05, Yuzuko Hosoya wrote: > > Indeed, it's problematic. I also did test and I found that this > > problem was occurred when any partition didn't match W

Re: Problem with default partition pruning

Hi. At Mon, 18 Mar 2019 18:44:07 +0900, Amit Langote wrote in <9bed6b79-f264-6976-b880-e2a5d23e9...@lab.ntt.co.jp> > > v2 patch attached. > > Could you please check it again? > > I think the updated patch breaks the promise that > get_matching_range_bounds won't set scan_default based on indiv

Re: Problem with default partition pruning

Hello. At Fri, 15 Mar 2019 17:30:07 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190315.173007.147577546.horiguchi.kyot...@lab.ntt.co.jp> > The patch relies on the fact(?) that the lowest index is always > -1 in range partition and uses it as pseudo default > partition. I'm not su

Re: Problem with default partition pruning

Hosoya-san, On 2019/03/15 15:05, Yuzuko Hosoya wrote: > Indeed, it's problematic. I also did test and I found that > this problem was occurred when any partition didn't match > WHERE clauses. So following query didn't work correctly. > > # explain select * from test1_3 where (id > 0 and id <

Re: Problem with default partition pruning

Hello. At Fri, 15 Mar 2019 15:05:41 +0900, "Yuzuko Hosoya" wrote in <001901d4daf5$1ef4f640$5cdee2c0$@lab.ntt.co.jp> > v2 patch attached. > Could you please check it again? I have some comments on the patch itself. The patch relies on the fact(?) that the lowest index is always -1 in range par

RE: Problem with default partition pruning

Hi Thibaut, Thanks a lot for your test and comments. > > Le 28/02/2019 à 09:26, Imai, Yoshikazu a écrit : > > Hosoya-san > > > > On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote: > >>> From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > >>> Sent: Wednesday, February 27, 2019 11:22 AM

Re: Problem with default partition pruning

Le 28/02/2019 à 09:26, Imai, Yoshikazu a écrit : > Hosoya-san > > On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote: >>> From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] >>> Sent: Wednesday, February 27, 2019 11:22 AM >>> >>> Hosoya-san, >>> >>> On 2019/02/22 17:14, Yuzuko Hosoya wrot

Re: Problem with default partition pruning

Hi Ibrar, On Tue, Mar 5, 2019 at 2:37 AM Ibrar Ahmed wrote: > > Hi Yuzuko Hosoya, > > Ignore my last message, I think this is also a legitimate scan on default > partition. > Oh, I got it. Thanks a lot. > > On Mon, Mar 4, 2019 at 10:29 PM Ibrar Ahmed wrote: >> >> Hi >> >> Patch work fine to

Re: Problem with default partition pruning

Imai-san, Thanks for sharing your tests! On Thu, Feb 28, 2019 at 5:27 PM Imai, Yoshikazu wrote: > > Hosoya-san > > On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote: > > > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > > > Sent: Wednesday, February 27, 2019 11:22 AM > > > > > > H

Re: Problem with default partition pruning

Hi Yuzuko Hosoya, Ignore my last message, I think this is also a legitimate scan on default partition. On Mon, Mar 4, 2019 at 10:29 PM Ibrar Ahmed wrote: > Hi > > Patch work fine to me, but I have one test case where default partition > still scanned. > > postgres=# explain select * from test

Re: Problem with default partition pruning

Hi Patch work fine to me, but I have one test case where default partition still scanned. postgres=# explain select * from test1 where (id < 10) and true; QUERY PLAN --- Ap

RE: Problem with default partition pruning

Hosoya-san On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote: > > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > > Sent: Wednesday, February 27, 2019 11:22 AM > > > > Hosoya-san, > > > > On 2019/02/22 17:14, Yuzuko Hosoya wrote: > > > Hi, > > > > > > I found the bug of default part

RE: Problem with default partition pruning

Amit-san, > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Wednesday, February 27, 2019 11:22 AM > > Hosoya-san, > > On 2019/02/22 17:14, Yuzuko Hosoya wrote: > > Hi, > > > > I found the bug of default partition pruning when executing a range query. > > > > - > > postgres=

Re: Problem with default partition pruning

Hosoya-san, On 2019/02/22 17:14, Yuzuko Hosoya wrote: > Hi, > > I found the bug of default partition pruning when executing a range query. > > - > postgres=# create table test1(id int, val text) partition by range (id); > postgres=# create table test1_1 partition of test1 for values from (0