ave done together will greatly benefit users managing
highly partitioned configurations. It has truly been an honor for me
to work closely with you and all the reviewers on this work. It would
be my pleasure to continue contributing to PostgreSQL.
--
Best regards,
Yuya Watari
appen in the attached v41 patch, and that's the last
> outstanding issue that I had for this.
>
> I think this is worthy of getting into v18. Does anyone else think
> differently? It'd be good to know that soon.
Thank you very much for sharing this new patch. It looks good to me,
and I'd also be very happy to see this committed in v18.
--
Best regards,
Yuya Watari
roach further.
> Given that we've only got a week left, I see little hope of getting
> any of this into v18.
I agree that addressing these issues within the remaining time is
challenging. The design clearly needs reconsideration. Therefore, I
will postpone these changes and submit a fully revised version for
v19. Would this approach be acceptable to you?
--
Best regards,
Yuya Watari
nd propose a refined patch set for v19. What do you
think about this approach?
Thank you again for your extensive contributions to this patch so far.
I'm sorry that I couldn't get it ready in time for v18.
[1]
https://www.postgresql.org/message-id/CAJ2pMkYR_X-%3Dpq%2B39-W5kc0OG7q9u5YUwDBCHnkPur17DXnxuQ%40mail.gmail.com
--
Best regards,
Yuya Watari
proaches and compare the memory usage to the
current version.
Thank you once again for conducting the benchmarks.
--
Best regards,
Yuya Watari
What do you think about this
approach?
[1]
https://www.postgresql.org/message-id/d8db5b4e-e358-2567-8c56-a85d2d8013df%40postgrespro.ru
[2]
https://www.postgresql.org/message-id/CAExHW5uVZ3E5RT9cXHaxQ_DEK7tasaMN%3DD6rPHcao5gcXanY5w%40mail.gmail.com
--
Best regards,
Yuya Watari
ot->eq_derives,
i);
Assert(bms_is_subset(relids, rinfo->clause_relids));
}
#endif
return edis;
}
=
[1]
https://www.postgresql.org/message-id/caexhw5stmouobe55pmt83r8uxvfcph+pvo5dnpdrvcsbgxe...@mail.gmail.com
--
Best regards,
Yu
t() ensures that the targetlist never contains
* any resjunk columns, so all eclasses that exist in 'root' must have
* received a new member in the loop above. Add them to the child_rel's
* eclass_indexes.
*/
child_rel->eclass_indexes = bms_add_range(child_rel->eclass_indexes, 0,
list_length(root->eq_classes) - 1);
}
=
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=66c0185a3d14bbbf51d0fc9d267093ffec735231
--
Best regards,
Yuya Watari
including yours, and share further information if found.
Again, I apologize for my late response and appreciate your kind review.
--
Best regards,
Yuya Watari
Hello,
On Wed, Nov 22, 2023 at 2:32 PM Yuya Watari wrote:
> Unfortunately, I've been busy due to work, so I won't be able to
> respond for several weeks. I'm really sorry for not being able to see
> the patches. As soon as I'm not busy, I will look at them, consi
7;m not busy, I will look at them, consider
the above approach, and reply to this thread. If there is no
objection, I will move this CF entry forward to next CF.
Again, thank you very much for looking at this thread, and I'm sorry
for my late work.
--
Best regards,
Yuya Watari
xes are just picked up from the previous patch, and I
have not changed their design. I think a similar approach to
EquivalenceMembers may be applied to RestrictInfos. I will experiment
with them and share a new patch.
--
Best regards,
Yuya Watari
ql.org/message-id/flat/64486b0b-0404-e39e-322d-0801154901f3%40postgrespro.ru
--
Best regards,
Yuya Watari
> top-level parent. If that can't be made to work, then maybe that shows
> the current patch has merit.
I really appreciate your detailed advice. I am sorry that I will not
be able to respond for a week or two due to my vacation, but I will
explore and work on these issues. Thanks again for your kind reply.
[1]
https://www.postgresql.org/message-id/CAJ2pMkYR_X-%3Dpq%2B39-W5kc0OG7q9u5YUwDBCHnkPur17DXnxuQ%40mail.gmail.com
--
Best regards,
Yuya Watari
e above
idea, but I should avoid the conflict if he is working on this. David,
what do you think about this? Is it OK to post a new patch to address
the review comments? I am looking forward to your reply.
--
Best regards,
Yuya Watari
ers do not care about
memory usage, so there is room for consideration. For example, making
the metrics optional in EXPLAIN ANALYZE outputs might be better.
--
Best regards,
Yuya Watari
lso a possible solution.
--
Best regards,
Yuya Watari
cient when there are
> thousands of partitions involved. See my comment at [2]
Thank you for pointing this out. I have never considered the memory
usage impact of this patch. As you say, the Bitmapset structure caused
this increase. I will try to look into this further.
--
Best regards,
Yuya Watari
nt queries than I have used in my benchmarks.
Thank you again for reviewing this.
--
Best regards,
Yuya Watari
Hello,
On Tue, Jul 4, 2023 at 9:36 AM David Rowley wrote:
> I've now pushed the patch.
Thanks for the commit!
--
Best regards,
Yuya Watari
ions
in the future.
--
Best regards,
Yuya Watari
| Speedup (Mean) | Speedup (Median)
v4 | 0.38% |0.31%
v4 with 0th word check | 0.30% |0.22%
--
Best regards,
Yuya Watari
/winkyao/join-order-benchmark
--
Best regards,
Yuya Watari
ortunately, some of the regression tests failed
with the v5 patch. These failures are due to the bug introduced by the
#3 change.
--
Best regards,
Yuya Watari
ssert failures here than, in
> the case of bms_get_singleton_member, some code accidentally doing the
> wrong thing based on a corrupt Bitmapset.
I agree with your change. I think failing by Assertion is better than
a runtime error or unexpected behavior.
--
Best regards,
Yuya Watari
Hello,
On Thu, Mar 16, 2023 at 10:30 AM Yuya Watari wrote:
> My idea is to compute the bitwise OR of all bitmapwords of the result
> Bitmapset. The bitwise OR can be represented as a single operation in
> the machine code and does not require any conditional branches. If the
> bitwis
r than the master when n is large. Its speed up
reached 167.1%. I think just adopting this optimization is worth
considering.
[1]
https://www.postgresql.org/message-id/caj2pmky10j_pa2jph5m-vooo6bvjntoo_-t_znu_poap0q1...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/caaphdvq9eq0w_afugrb6ba2
artition is also
partitioned in your workload, I think the result of 1415ms is
reasonable.
--
Best regards,
Yuya Watari
v9-0001-Apply-eclass_member_speedup_v3.patch.patch
Description: Binary data
v9-0002-Revert-one-of-the-optimizations.patch
Description: Binary data
v9-0003-Use-conventional-algor
Hello,
I noticed that the previous patch does not apply to the current HEAD.
I attached the rebased version to this email.
--
Best regards,
Yuya Watari
v8-0001-Apply-eclass_member_speedup_v3.patch.patch
Description: Binary data
v8-0002-Revert-one-of-the-optimizations.patch
Description
Hello,
On Wed, Sep 21, 2022 at 6:43 PM Yuya Watari wrote:
> 1.1. Revert one of our optimizations (v5)
>
> As I mentioned in the comment in
> v[5|6|7]-0002-Revert-one-of-the-optimizations.patch, I reverted one of
> our optimizations. This code tries to find EquivalenceMember
also think introducing EquivalenceMemberIterator is one
good alternative solution. I will try to implement and test it.
Thank you again for helping me.
--
Best regards,
Yuya Watari
Dear David,
Thank you for sharing your new idea.
I agree that introducing a Bitmapset field may solve this problem. I
will try this approach in addition to previous ones.
Thank you again for helping me.
--
Best regards,
Yuya Watari
n a few weeks.
--
Best regards,
Yuya Watari
that use a RelOptInfo.
Thank you for giving your idea. I will try to polish up my algorithm
based on your suggestion.
--
Best regards,
Yuya Watari
tch does not work with the current HEAD.
I attached the modified one to this email.
Additionally, I added my patch to the current commit fest [1].
[1] https://commitfest.postgresql.org/38/3701/
--
Best regards,
Yuya Watari
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
ing
default behavior to off is one of the realistic solutions.
Best regards,
Yuya Watari
there is no need to impose a penalty of 860%,
but a penalty of about 1% is enough.
This approach of introducing resultcache_cost_factor is not an
essential solution. However, it is reasonable to offer a way of
controlling the aggressiveness of the result cache.
Repeatedly, this patch is exper
dexes that you've created. I see the
> tool from the transaction processing council for TPC-DS only comes
> with the list of tables.
>
> Can you share the output of:
I listed all indexes on my machine by executing your query. I attached
the resu
8%
Although there is variation in the execution time, the speedup ratio
is around -10%. So, the result cache has a 10% regression in query 62.
The overhead of EXPLAIN ANALYZE and TIMING ON do not seem to be high.
Best regards,
Yuya Watari
On Tue, Apr 13, 2021 at 7:13 PM David Rowley wrote:
have to change its
default behavior.
Best regards,
Yuya Watari
QUERY PLAN
comments. I had to add more
information about these macros.
> I fixed those things and pushed it.
Thank you very much for the commit!
Best regards,
Yuya Watari
NTT Software Innovation Center
watari.y...@gmail.com
to an arithmetic before
> checking if it is NaN. That seems have a chance of exception.
Thank you for pointing it out. That's my mistake. I fixed it and
attached the patch.
Best regards,
Yuya Watari
NTT Software Innovation Center
watari.y...@gmail.com
v6-keep-compiler-silence.patch
Description: Binary data
nguage specification. The
modified patch (attached in the previous e-mail) checks NaN explicitly
if needed.
Best regards,
Yuya Watari
NTT Software Innovation Center
watari.y...@gmail.com
Hello Tom,
Thank you for replying.
On Wed, Nov 6, 2019 at 12:04 AM Tom Lane wrote:
>
> Yuya Watari writes:
> > The added macro FLOAT8_FITS_IN_INT32() does not check NaN explicitly,
> > but it sufficiently handles the case.
>
> Really? I don't think anything is gu
um < (float8) PG_INT32_MIN ||
-num >= -((float8) PG_INT32_MIN) ||
-isnan(num)))
+ /* Range check */
+ if (unlikely(!FLOAT8_FITS_IN_INT32(num)))
=
The added macro FLOAT8_FITS_IN_INT32() does not check NaN explicitly,
but it sufficiently handles the case.
Best regards,
owever, further consideration is needed for different
architectures.
I attached the modified patch. In the patch, I placed the macro in
"src/include/c.h", but this may not be a good choice because c.h is
widely included from a lot of files. Do you have any good ideas about
its placement?
Thanks,
5808
===
I think the code should be "result_double >= (double) PG_INT64_MAX",
that is we have to use >= rather than >. I attached the modified
patch.
Thanks,
Yuya Watari
NTT Software Innovation Center
watari.y...@gmail.com
2019年9月27日(金) 12:00 Yuya Watari :
>
&g
===
This warning is due to implicit conversion from PG_INT64_MAX to double,
which drops the precision as described in the warning. This drop is not a
problem in this case, but we have to get rid of useless warnings. Attached
patch casts PG_INT64_MAX explicitly.
Thanks,
Yuya Watari
NTT Software Innovation Center
watari.y...@gmail.com
keep-compiler-silence.patch
Description: Binary data
48 matches
Mail list logo
