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
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
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.
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:
-> 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
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
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
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
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
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]
> >&
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
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
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
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
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 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
the patch to fix it.
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center
fix_partprune_typo.patch
Description: Binary data
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
