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]
> >&
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
quot;.
# explain select * from test2_0_20 where id = 25;
QUERY PLAN
-------
Append (cost=0.00..25.91 rows=6 width=36)
-> Seq Scan on test2_10_20_def (cost=0.00..25.88 rows=6 width=36)
Filter: (id = 25)
As Amit described in the previous email, id = 25 contradicts test2_0_20's
partition constraint, so I think this clause should be ignored and we can
also handle this case in the similar way as Amit proposal.
I attached v1-delta-2.patch which fix the above issue.
What do you think about it?
Best regards,
Yuzuko Hosoya
v1-delta-2.patch
Description: Binary data
constraint
> is not loaded by the planner. Note that pruning is only used if a query
> specifies the parent table,
> not a partition.
Thanks for the comments.
I saw that email. Also, I checked that query Thibaut mentioned worked
correctly with Amit's patch discussed in that thread.
Best regards,
Yuzuko Hosoya
ition constraint,
> fixing problems unearthed by Thibaut's tests
I attached the latest patches according to Amit comment.
v3_default_partition_pruning.patch fixes default partition pruning problems
and ignore_contradictory_where_clauses_at_partprune_step.patch fixes
sub-partition problems Thi
-> Seq Scan on rlp3_default (cost=0.00..25.88 rows=6 width=36)
Filter: (a = 2)
(9 rows)
-
I think that the place of check contradiction process was wrong
At ignore_contradictory_where_clauses_at_partprune_step.patch.
So I fixed it.
Attached the latest patches. Please check it again.
Best regards,
Yuzuko Hosoya
v2_ignore_contradictory_where_clauses_at_partprune_step.patch
Description: Binary data
v4_default_partition_pruning.patch
Description: Binary data
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:
t attributes. Specifically just after the for loop "for (i =
> > 0 ; i < part_scheme->partnattrs; i++)".
>
I think we should check whether WHERE clause contradicts partition
constraint even when the clause matches part attributes.
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
0 ms
Execution Time: 0.070 ms
(6 rows)
I realized t1_1 was not scanned actually since "never executed"
was displayed in the plan using EXPLAIN ANALYZE. But I think
"One-Time Filter: false" and "Subplans Removed: ALL" or something
like that should be displayed instead.
What do you think?
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center
the patch to fix it.
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center
fix_partprune_typo.patch
Description: Binary data
Hi Michael,
> From: Michael Paquier [mailto:mich...@paquier.xyz]
> Sent: Thursday, November 08, 2018 8:17 PM
>
> On Thu, Nov 08, 2018 at 07:19:14PM +0900, Yuzuko Hosoya wrote:
> > Here is the patch to fix it.
>
> Thanks, committed.
Thank you.
Yuzuko Hosoya
NTT Open Source Software Center
s:
- get_matching_range_bounds() determines only offsets of range bounds
according to each condition
- These results are combined at perform_pruning_combine_step()
- Whether the default partition is scanned or not is determined at
get_matching_partitions()
Attached the patch. Any feedback is gre
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 ran
u have any thoughts?
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=4c2777d0b733220d9029f78817af8ce
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center
improve_selectivity_estimate_for_range_queries.patch
Description: Binary data
Hi,
Thanks for the comments.
I attach the v2 patch.
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> Sent: Friday, December 21, 2018 12:25 PM
>
> Hello.
>
> At Thu, 20 Dec 2018 17:21:29 +0900, "Yuzuko Hosoya"
> wrote in
> <008701d4
his case, even though it's a narrow pain point. So I tried
distinguishing
explicitly between real estimates and otherwise as Robert said.
The idea Tom proposed and Horiguchi-san tried seems reasonable, but I'm
concerned whether
any range queries really cannot match 0.342 (or some such) by
accident in any
environments. Is the way which Horiguchi-san did enough to prove that?
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center
Hello,
I'm Yuzuko Hosoya. This is my first PostgreSQL project participation.
I have been developing partitioning advisor prototype with Julien Rouhaud.
It will be a new feature of HypoPG[1], which is a PostgreSQL extension, and
will help partitioning design tuning. Currently, HypoPG
18 matches
Mail list logo
