On Wed, Apr 9, 2025 at 2:21 PM David Rowley wrote:
> On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> > Should the following paragraph in src/backend/optimizer/README be
> > updated to reflect the new reality after recent changes?
> >
> > An EquivalenceClass can contain "em_is_child" member
Hello David,
On Tue, Apr 8, 2025 at 3:31 PM David Rowley wrote:
>
> I've pushed the patch now. Thanks for all the reviews of my adjustments.
Thank you very much for pushing the patch! I also wish to extend my
deepest thanks to everyone who has contributed to reviewing and
improving this patch.
On Thu, Apr 10, 2025 at 2:35 PM David Rowley wrote:
> On Thu, 10 Apr 2025 at 16:57, Amit Langote wrote:
> >
> > On Thu, Apr 10, 2025 at 12:03 PM David Rowley wrote:
> > > -Most operations on EquivalenceClasses should ignore child members.
> > > +Most operations on EquivalenceClasses needn't look
On Thu, 10 Apr 2025 at 16:57, Amit Langote wrote:
>
> On Thu, Apr 10, 2025 at 12:03 PM David Rowley wrote:
> > -Most operations on EquivalenceClasses should ignore child members.
> > +Most operations on EquivalenceClasses needn't look at child members.
> >
> > Would that be ok?
>
> Yeah, I think
On Thu, Apr 10, 2025 at 12:03 PM David Rowley wrote:
> On Wed, 9 Apr 2025 at 17:38, Amit Langote wrote:
> > Still, maybe a tiny tweak to the last line could help steer readers
> > right without diving into storage. How about:
> >
> > Most operations on EquivalenceClasses should ignore child membe
On Wed, 9 Apr 2025 at 17:38, Amit Langote wrote:
> Still, maybe a tiny tweak to the last line could help steer readers
> right without diving into storage. How about:
>
> Most operations on EquivalenceClasses should ignore child members,
> which are stored separately from normal members.
I think
Hi David,
On Wed, Apr 9, 2025 at 5:12 AM David Rowley wrote:
> On Wed, 9 Apr 2025 at 02:24, Tom Lane wrote:
> >
> > David Rowley writes:
> > > I've pushed the patch now. Thanks for all the reviews of my adjustments.
> >
> > Shouldn't the CF entry be marked committed?
>
> I've done that now.
Sh
Amit Langote writes:
> Should the following paragraph in src/backend/optimizer/README be
> updated to reflect the new reality after recent changes?
> An EquivalenceClass can contain "em_is_child" members, which are copies
> of members that contain appendrel parent relation Vars, transpose
On Wed, Apr 9, 2025 at 10:51 AM David Rowley wrote:
>
> On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> > Should the following paragraph in src/backend/optimizer/README be
> > updated to reflect the new reality after recent changes?
> >
> > An EquivalenceClass can contain "em_is_child" mem
On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> Should the following paragraph in src/backend/optimizer/README be
> updated to reflect the new reality after recent changes?
>
> An EquivalenceClass can contain "em_is_child" members, which are copies
> of members that contain appendrel pa
On Wed, 9 Apr 2025 at 02:24, Tom Lane wrote:
>
> David Rowley writes:
> > I've pushed the patch now. Thanks for all the reviews of my adjustments.
>
> Shouldn't the CF entry be marked committed?
I've done that now.
88f55bc97 added code to do faster lookups of ec_derives clauses, so I
think that
David Rowley writes:
> I've pushed the patch now. Thanks for all the reviews of my adjustments.
Shouldn't the CF entry be marked committed?
> Thanks to Yuya for persisting on this for so many years. I was
> impressed with that persistence and also with your very detailed and
> easy to understand
On Tue, 8 Apr 2025 at 17:41, Ashutosh Bapat
wrote:
> Thanks for listing all the patterns. Creating four different iterators
> is going to affect functionality and might require duplicate code. But
> each of the patterns is using exactly one BMS operation on em_relids
> and relids being used as sea
On Tue, Apr 8, 2025 at 8:30 AM David Rowley wrote:
>
> On Tue, 8 Apr 2025 at 04:54, Ashutosh Bapat
> wrote:
> > - foreach(lc2, cur_ec->ec_members)
> > + setup_eclass_member_iterator(&it, cur_ec, rel);
> > + while ((cur_em = eclass_member_iterator_next(&it)) != NULL)
> > {
> > - EquivalenceMember
David Rowley writes:
> I certainly could get on board with renaming if there's consensus to
> do so. I don't think that's going to happen in the next 9 hours. Is it
> worth pushing this out to v19 because we can't agree on the name of a
> struct field? I'd be disappointed if we miss this because o
On Tue, 8 Apr 2025 at 04:54, Ashutosh Bapat
wrote:
> - foreach(lc2, cur_ec->ec_members)
> + setup_eclass_member_iterator(&it, cur_ec, rel);
> + while ((cur_em = eclass_member_iterator_next(&it)) != NULL)
> {
> - EquivalenceMember *cur_em = (EquivalenceMember *) lfirst(lc2);
> -
> /*
> * Ignore chi
On Mon, Apr 7, 2025 at 4:34 AM David Rowley wrote:
>
> On Sat, 5 Apr 2025 at 16:55, David Rowley wrote:
> > I am still thinking about the duplicate members being returned from
> > the iterator for child join rels due to them being duplicated into
> > each component relid element in ec_childmember
David Rowley writes:
> I think this is worthy of getting into v18. Does anyone else think
> differently? It'd be good to know that soon.
v41 passes an eyeball check for me.
regards, tom lane
Hello David,
Thank you very much for updating the patches and clearly addressing
these points.
On Mon, Apr 7, 2025 at 8:04 AM David Rowley wrote:
>
> I used the attached .txt file to highlight the places where the
> iterator returned the same member twice and saw only that
> find_ec_member_match
On Sat, 5 Apr 2025 at 16:55, David Rowley wrote:
> I am still thinking about the duplicate members being returned from
> the iterator for child join rels due to them being duplicated into
> each component relid element in ec_childmembers. I did consider if
> these could just not be duplicated and
On Fri, 14 Mar 2025 at 23:10, Yuya Watari wrote:
> I have refactored the patches based on your feedback and attached the
> updated versions (v34). Additionally, I have included a diff between
> v33 and v34 for your quick reference.
Thanks for updating the patch. I've looked at v34-0001. Here are
Hello Tom,
Thank you for your detailed review, and apologies for my late response.
On Tue, Mar 25, 2025 at 2:49 AM Tom Lane wrote:
>
> One thing I don't love is putting the children into RelOptInfos.
> That seems like an unrelated data structure. Have you thought
> about instead having, in each
On Sat, 5 Apr 2025 at 04:05, Tom Lane wrote:
> This patchset has a distinct whiff of unseemly haste.
hmm, yes. I would like to give this patch as good a chance at making
v18 as I can, and I admit to having optimised for that. Seemingly,
we've got a few other good partitioning performance patches
Hello David,
Thank you for your prompt reply, and apologies for my late response.
On Mon, Mar 24, 2025 at 2:38 PM David Rowley wrote:
>
> I understand Ashutosh would like to handle the RestrictInfo speedup
> another way, so there's additional review work to do there to
> determine the merits of
Hi David,
On Fri, Apr 4, 2025 at 11:34 AM David Rowley wrote:
>
> I also did some benchmarking using the attached script. I've attached
> the results of running that on my AMD Zen2 machine. See the end of the
> script for the CREATE TABLE statement for loading that into postgres.
>
> The results
David Rowley writes:
> I've attached the updated set of patches.
This patchset has a distinct whiff of unseemly haste.
1. The commit message for 0002 still claims that child EC members
are kept in RelOptInfos, precisely the point I objected to upthread.
I see that in fact that's untrue, but it'd
Thank you for having a look at this.
On Fri, 4 Apr 2025 at 21:47, Amit Langote wrote:
> It looks to me like the following hunks in 0002 probably belong in
> 0001, unless you’re planning to commit the patches together anyway:
Ah, yeah. Unsure about that as yet, but I've moved it over.
> The comm
On Sat, 5 Apr 2025 at 02:54, Ashutosh Bapat
wrote:
> I haven't measured if the patches improve performance of simple scans
> with thousands of partitions. Have you tried measuring that?
I just tried 10k partitions on my Zen4 laptop.
create table lp (a int) partition by list(a);
select 'create ta
Hi David,
Impressive results!
On Fri, Apr 4, 2025 at 3:05 PM David Rowley wrote:
> I've done some further work on this, mostly relating to the code
> comments.
It looks to me like the following hunks in 0002 probably belong in
0001, unless you’re planning to commit the patches together anyway:
On Fri, 4 Apr 2025 at 00:34, David Rowley wrote:
> I've attached 2 patches, which I think addresses most of this, aside
> from the last point.
>
> These do need more work. I've just attached what I have so far before
> I head off for the day. I am planning on running some performance
> tests tomor
On Tue, 25 Mar 2025 at 06:49, Tom Lane wrote:
> I finally made some time to look at this patchset, and I'm pretty
> disappointed, because after 35 versions I'd expect to see something
> that looks close to committable. This doesn't really. I like the
> basic idea of taking child EC members out o
Hello Ashutosh,
Thank you for your detailed review, and apologies for my delayed response.
On Thu, Mar 27, 2025 at 1:42 PM Ashutosh Bapat
wrote:
>
> Here are memory consumption numbers using list_free() instead of pfree(),
> using the same method as [1], using a binary without asserts and debug
On Mon, Mar 24, 2025 at 11:08 AM David Rowley wrote:
> 2. You should use list_free() in the following:
>
> /*
> * XXX Should we use list_free()? I decided to use this style to take
> * advantage of speculative execution.
> */
> if (unlikely(it->list_is_copy))
> pfree(it->ec_members);
>
> The
David Rowley writes:
> ... The main
> thing I'd like to understand here is if there's not enough time to get
> the entire patch set committed, is there much benefit to just having
> the EquivalenceMember index stuff in by itself without the
> RestrictInfo changes.
I finally made some time to look
Thank you for addressing those comments.
On Mon, 24 Mar 2025 at 12:24, Yuya Watari wrote:
> It is true that currently, indexes for EquivalenceMembers do not store
> information about base rels. However, the subsequent commit (v35-0004)
> introduces indexes for base rels to enable faster RestrictI
On Sat, 1 Mar 2025 at 23:07, Yuya Watari wrote:
> The previous patches did not apply to the current master, so I have
> rebased them.
Thank you for continuing to work on this. My apologies for having
completely disappeared from this thread for so long.
Looking at v33-0001, there are a few choice
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi Yuya,
Tested this patch and noted that this patch signific
Hello,
On 2024-Dec-13, Yuya Watari wrote:
> Thank you for your reply, and I'm sorry if my previous emails caused
> confusion or made it seem like I was ignoring more important issues.
Not to worry!
> > Memory usage and planning time in production builds [are] important.
> > You can better spend
Hello Alvaro,
Thank you for your reply, and I'm sorry if my previous emails caused
confusion or made it seem like I was ignoring more important issues.
On Thu, Dec 12, 2024 at 9:09 PM Alvaro Herrera wrote:
>
> I'm repeating myself, but I disagree that this is something we should
> spend _any_ ti
Hello Yuya,
On 2024-Dec-11, Yuya Watari wrote:
> On Tue, Dec 3, 2024 at 7:38 PM Alvaro Herrera wrote:
> >
> > I don't think planning time in assert-enabled builds is something we
> > should worry about, at all. Planning time in production builds is the
> > important one.
>
> Thank you for your
Hello Ashutosh and Alvaro,
I appreciate you replying to the email.
On Tue, Dec 3, 2024 at 7:38 PM Alvaro Herrera wrote:
>
> I don't think planning time in assert-enabled builds is something we
> should worry about, at all. Planning time in production builds is the
> important one.
Thank you fo
On Tue, Dec 3, 2024 at 4:08 PM Alvaro Herrera wrote:
>
> Hello,
>
> On 2024-Dec-03, Ashutosh Bapat wrote:
>
> > For one of the earlier versions, I had reported a large memory
> > consumption in all cases and increase in planning time for Assert
> > enabled builds. How does the latest version perfo
Hello,
On 2024-Dec-03, Ashutosh Bapat wrote:
> For one of the earlier versions, I had reported a large memory
> consumption in all cases and increase in planning time for Assert
> enabled builds. How does the latest version perform in those aspects?
I don't think planning time in assert-enabled
On Mon, Dec 2, 2024 at 2:22 PM Yuya Watari wrote:
>
> 4. Discussion
>
> First of all, tables 1, 2 and the figure attached to this email show
> that likely and unlikely do not have the effect I expected. Rather,
> tables 3, 4, 5 and 6 imply that they can have a negative effect on
> queries A and B
> On Tue, Oct 15, 2024 at 12:20:04PM GMT, Yuya Watari wrote:
>
> The previous patches do not apply to the current master, so I have
> attached the rebased version.
Thanks for keeping it up to date.
> v25-0001
> This patch is one of the main parts of my optimization. Traditionally,
> EquivalenceCl
Hello,
Thank you for reviewing these patches.
On Thu, May 2, 2024 at 11:35 PM jian he wrote:
> on v24-0001:
> +/*
> + * add_eq_member - build a new EquivalenceMember and add it to an EC
> + */
> +static EquivalenceMember *
> +add_eq_member(EquivalenceClass *ec, Expr *expr, Relids relids,
> + Jo
On Thu, May 2, 2024 at 3:57 PM Yuya Watari wrote:
>
hi. sorry to bother you, maybe a dumb question.
trying to understand something under the hood.
currently I only applied
v24-0001-Speed-up-searches-for-child-EquivalenceMembers.patch.
on v24-0001:
+/*
+ * add_eq_member - build a new Equivalence
Hello Ashutosh,
Thank you for your email and for reviewing the patch. I sincerely
apologize for the delay in responding.
On Wed, Mar 6, 2024 at 11:16 PM Ashutosh Bapat
wrote:
> here's summary of observations
> 1. The patch improves planning time significantly (3X to 20X) and the
> improvement i
Hi Yuya
On Wed, Feb 28, 2024 at 4:48 PM Yuya Watari wrote:
> Hello,
>
> On Tue, Feb 13, 2024 at 6:19 AM Alena Rybakina
> wrote:
> >
> > Yes, it is working correctly now with the assertion check. I suppose
> > it's better to add this code with an additional comment and a
> > recommendation for o
Hi! Sorry my delayed reply too.
On 17.01.2024 12:33, Yuya Watari wrote:
Hello Alena,
Thank you for your quick response, and I'm sorry for my delayed reply.
On Sun, Dec 17, 2023 at 12:41 AM Alena Rybakina
wrote:
I thought about this earlier and was worried that the index links of the
equival
Hi!
On 13.12.2023 09:21, Yuya Watari wrote:
Hello Alena, Andrei, and all,
I am sorry for my late response. I found that the current patches do
not apply to the master, so I have rebased those patches. I have
attached v22. For this later discussion, I separated the rebasing and
bug fixing that Al
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, consider
> the above approach, and repl
Hello Alena, Andrei, and all,
Thank you for reviewing this patch. I really apologize for not
updating this thread for a while.
On Sat, Nov 18, 2023 at 6:04 AM Alena Rybakina wrote:
> Hi, all!
>
> While I was reviewing the patches, I noticed that they needed some rebasing,
> and in one of the pa
On 27/9/2023 14:28, Yuya Watari wrote:
Thank you for pointing it out. The ec_source_indexes and
ec_derive_indexes 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
wi
John Naylor writes:
> On Sat, Nov 18, 2023 at 4:04 AM Alena Rybakina
> wrote:
>> All diff files have already been added to
>> v21-0002-Introduce-indexes-for-RestrictInfo patch.
> Unfortunately, the patch tester is too smart for its own good, and
> will try to apply .diff files as well.
Yeah -
On Sat, Nov 18, 2023 at 4:04 AM Alena Rybakina wrote:
>
> All diff files have already been added to
> v21-0002-Introduce-indexes-for-RestrictInfo patch.
Unfortunately, the patch tester is too smart for its own good, and
will try to apply .diff files as well. Since
bug_related_to_atomic_function.
Hello Ashutosh and Andrey,
On Wed, Sep 20, 2023 at 8:03 PM Ashutosh Bapat
wrote:
> While working on RestrictInfo translations patch I was thinking on
> these lines. [1] uses hash table for storing translated RestrictInfo.
> An EC can have a hash table to store ec_member translations. The same
> p
On Wed, Sep 20, 2023, at 5:04 PM, Yuya Watari wrote:
> On Tue, Sep 19, 2023 at 5:21 PM Andrey Lepikhov
> wrote:
>> Working on self-join removal in the thread [1] nearby, I stuck into the
>> problem, which made an additional argument to work in this new direction
>> than a couple of previous ones.
On Wed, Sep 20, 2023 at 3:35 PM Yuya Watari wrote:
> I think we may be able to remove the eclass_child_members field by
> making child members on demand. v20 makes child members at
> add_[child_]join_rel_equivalences() and adds them into
> RelOptInfo->eclass_child_members. Instead of doing that,
Hello Ashutosh and Andrey,
Thank you for your email, and I really apologize for my late response.
On Thu, Sep 7, 2023 at 3:43 PM Ashutosh Bapat
wrote:
> It seems that you are still investigating and fixing issues. But the
> CF entry is marked as "needs review". I think a better status is
> "WoA
On 25/8/2023 14:39, Yuya Watari wrote:
Hello,
On Wed, Aug 9, 2023 at 8:54 PM David Rowley wrote:
I think the best way to move this forward is to explore not putting
partitioned table partitions in EMs and instead see if we can
translate to top-level parent before lookups. This might just be t
Hi Yuya,
On Fri, Aug 25, 2023 at 1:09 PM Yuya Watari wrote:
>
> 3. Future works
>
> 3.1. Redundant memory allocation of Lists
>
> When we need child EquivalenceMembers in a loop over ec_members, v20
> adds them to the list. However, since we cannot modify the ec_members,
> v20 always copies it. I
Hello David,
I really appreciate your quick reply.
On Wed, Aug 9, 2023 at 7:28 PM David Rowley wrote:
> If 0004 is adding an em_index to mark the index into
> PlannerInfo->eq_members, can't you use that in
> setup_eclass_member[_strict]_iterator to loop to verify that the two
> methods yield the
On Wed, 9 Aug 2023 at 20:15, Yuya Watari wrote:
> I agree with your opinion that my patch lacks some explanations, so I
> will consider adding more comments. However, I received the following
> message from David in March.
>
> On Thu, Mar 9, 2023 at 6:23 AM David Rowley wrote:
> > For the main pa
On Wed, 9 Aug 2023 at 22:28, David Rowley wrote:
> i.e:
>
> + Bitmapset *matching_ems = NULL;
> + memcpy(&idx_iter, iter, sizeof(EquivalenceMemberIterator));
> + memcpy(&noidx_iter, iter, sizeof(EquivalenceMemberIterator));
> +
> + idx_iter.use_index = true;
> + noidx_iter.use_index = false;
> +
>
On Wed, 5 Jul 2023 at 21:58, Yuya Watari wrote:
>
> Hello,
>
> On Fri, Mar 10, 2023 at 5:38 PM Yuya Watari wrote:
> > Thank you for pointing it out. I have attached the rebased version to
> > this email.
>
> Recent commits, such as a8c09daa8b [1], have caused conflicts and
> compilation errors in
Hello Andrey, Ashutosh, and David,
Thank you for your reply and for reviewing the patch.
On Mon, Aug 7, 2023 at 5:51 PM Andrey Lepikhov
wrote:
> One more thing: I think, you should add comments to
> add_child_rel_equivalences() and add_child_join_rel_equivalences()
> on replacing of:
>
> if (bms
Hi Andrey,
On Tue, Aug 8, 2023 at 8:52 AM Andrey Lepikhov
wrote:
> It is a positive thing to access some planner internals from the
> console, of course. My point is dedicated to the structuration of an
> EXPLAIN output and is caused by two reasons:
> 1. I use the EXPLAIN command daily to identif
On 7/8/2023 19:15, Ashutosh Bapat wrote:
On Mon, Aug 7, 2023 at 2:21 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
>> Do you think that the memory measurement patch I have shared in
those threads is useful in itself? If so, I will start another
proposal to address
On Mon, Aug 7, 2023 at 2:21 PM Andrey Lepikhov
wrote:
> >> Do you think that the memory measurement patch I have shared in those
> threads is useful in itself? If so, I will start another proposal to
> address it.
> >
> > For me, who is developing the planner in this thread, the memory
> > measur
On 7/8/2023 15:19, Yuya Watari wrote:
Hello,
Thank you for your reply.
On Thu, Aug 3, 2023 at 10:29 PM Ashutosh Bapat
wrote:
If you think that the verification is important to catch bugs, you may want to
encapsulate it with an #ifdef .. #endif such that the block within is not
compiled by d
Hello,
Thank you for your reply.
On Thu, Aug 3, 2023 at 10:29 PM Ashutosh Bapat
wrote:
> If you think that the verification is important to catch bugs, you may want
> to encapsulate it with an #ifdef .. #endif such that the block within is not
> compiled by default. See OPTIMIZER_DEBUG for exa
On Wed, Aug 2, 2023 at 12:11 PM Yuya Watari wrote:
> Hello,
>
> I really appreciate sharing very useful scripts and benchmarking results.
>
> On Fri, Jul 28, 2023 at 6:51 PM Ashutosh Bapat
> wrote:
> > Given that most of the developers run assert enabled builds it would
> > be good to bring down
Hello,
On Wed, Aug 2, 2023 at 6:43 PM Andrey Lepikhov
wrote:
> You introduced list_ptr_cmp as an extern function of a List, but use it
> the only under USE_ASSERT_CHECKING ifdef.
> Maybe you hide it under USE_ASSERT_CHECKING or remove all the stuff?
Thank you for your quick reply and for pointin
On 2/8/2023 13:40, Yuya Watari wrote:
As seen from the above, verifying iteration results was the cause of
the performance degradation. I agree that we should avoid such
degradation because it negatively affects the development of
PostgreSQL. Removing the verification when committing this patch i
Hello,
I really appreciate sharing very useful scripts and benchmarking results.
On Fri, Jul 28, 2023 at 6:51 PM Ashutosh Bapat
wrote:
> Given that most of the developers run assert enabled builds it would
> be good to bring down the degradation there while keeping the
> excellent speedup in non
Hi Yuya, Andrey,
On Fri, Jul 28, 2023 at 9:58 AM Andrey Lepikhov
wrote:
> >>
> > Discovering quality of partition pruning at the stage of execution
> > initialization and using your set of patches I have found some dubious
> > results with performance degradation. Look into the test case in
> >
Hello,
On Fri, Jul 28, 2023 at 1:27 PM Andrey Lepikhov
wrote:
> Sorry for this. It was definitely a false alarm. In this patch,
> assertion checking adds much overhead. After switching it off, I found
> out that this feature solves my problem with a quick pass through the
> members of an equivale
On 5/7/2023 16:57, Yuya Watari wrote:
Hello,
On Fri, Mar 10, 2023 at 5:38 PM Yuya Watari wrote:
Thank you for pointing it out. I have attached the rebased version to
this email.
Recent commits, such as a8c09daa8b [1], have caused conflicts and
compilation errors in these patches. I have atta
On Thu, 9 Mar 2023 at 01:34, Alvaro Herrera wrote:
> David, do you intend to continue to be involved in reviewing this one?
Yes. I'm currently trying to make a few Bitmapset improvements which
include the change made in this thread's 0001 patch over on [1].
For the main patch, I've been starting
Hello Watari-san, this patch does not currently apply. Could you please
rebase?
David, do you intend to continue to be involved in reviewing this one?
Thanks to both,
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"All rings of power are equal,
But some rings
On 2/6/23 06:47, Yuya Watari wrote:
Of course, I'm not sure if my approach in v16-0003 is ideal, but it
may help solve your concern above. Since simple_rel_array[0] is no
longer necessary with my patch, I removed the setup_append_rel_entry()
function in v16-0004. However, to work the patch, I nee
On Mon, 5 Dec 2022 at 21:28, David Rowley wrote:
>
> On Tue, 6 Dec 2022 at 04:45, Thom Brown wrote:
> > Testing your patches with the same 1024 partitions, each with 64
> > sub-partitions, I get a planning time of 205.020 ms, which is now a
> > 1,377x speedup. This has essentially reduced the pl
On Tue, 6 Dec 2022 at 04:45, Thom Brown wrote:
> Testing your patches with the same 1024 partitions, each with 64
> sub-partitions, I get a planning time of 205.020 ms, which is now a
> 1,377x speedup. This has essentially reduced the planning time from a
> catastrophe to a complete non-issue. H
On Sun, 4 Dec 2022 at 00:35, David Rowley wrote:
>
> On Tue, 29 Nov 2022 at 21:59, Yuya Watari wrote:
> > Thank you for testing the patch with an actual query. This speedup is
> > very impressive. When I used an original query with 1024 partitions,
> > its planning time was about 200ms. Given tha
Dear Andrey and Thom,
Thank you for reviewing and testing the patch. I really apologize for
my late response.
On Tue, Nov 8, 2022 at 8:31 PM Andrey Lepikhov
wrote:
> Looking into find_em_for_rel() changes I see that you replaced
> if (bms_is_subset(em->em_relids, rel->relids)
> with assertion st
On Thu, 17 Nov 2022 at 11:20, Thom Brown wrote:
>
> On Thu, 17 Nov 2022 at 09:31, Alvaro Herrera wrote:
> >
> > On 2022-Nov-16, Thom Brown wrote:
> >
> > > Once the issue Tom identified has been resolved, I'd like to test
> > > drive newer patches.
> >
> > What issue? If you mean the one from th
On Thu, 17 Nov 2022 at 09:31, Alvaro Herrera wrote:
>
> On 2022-Nov-16, Thom Brown wrote:
>
> > Once the issue Tom identified has been resolved, I'd like to test
> > drive newer patches.
>
> What issue? If you mean the one from the thread "Reducing
> duplicativeness of EquivalenceClass-derived cl
On 2022-Nov-16, Thom Brown wrote:
> Once the issue Tom identified has been resolved, I'd like to test
> drive newer patches.
What issue? If you mean the one from the thread "Reducing
duplicativeness of EquivalenceClass-derived clauses", that patch is
already applied (commit a5fc46414deb), and Yu
On Mon, 7 Nov 2022 at 06:33, Zhang Mingli wrote:
>
> HI,
>
> Regards,
> Zhang Mingli
> On Nov 7, 2022, 14:26 +0800, Tom Lane , wrote:
>
> Andrey Lepikhov writes:
>
> I'm still in review of your patch now. At most it seems ok, but are you
> really need both eq_sources and eq_derives lists now?
>
>
On 2/11/2022 15:27, Yuya Watari wrote:
I noticed that the previous patch does not apply to the current HEAD.
I attached the rebased version to this email.
Looking into find_em_for_rel() changes I see that you replaced
if (bms_is_subset(em->em_relids, rel->relids)
with assertion statement.
Accord
HI,
Regards,
Zhang Mingli
On Nov 7, 2022, 14:26 +0800, Tom Lane , wrote:
> Andrey Lepikhov writes:
> > I'm still in review of your patch now. At most it seems ok, but are you
> > really need both eq_sources and eq_derives lists now?
>
> Didn't we just have this conversation? eq_sources needs to b
Andrey Lepikhov writes:
> I'm still in review of your patch now. At most it seems ok, but are you
> really need both eq_sources and eq_derives lists now?
Didn't we just have this conversation? eq_sources needs to be kept
separate to support the "broken EC" logic. We don't want to be
regurgitat
On 2/11/2022 15:27, Yuya Watari wrote:
Hello,
I noticed that the previous patch does not apply to the current HEAD.
I attached the rebased version to this email.
I'm still in review of your patch now. At most it seems ok, but are you
really need both eq_sources and eq_derives lists now? As I s
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: Binar
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 EquivalenceMembers that do
> not satisfy
Dear David,
On Fri, Aug 26, 2022 at 12:18 PM David Rowley wrote:
> How about instead of doing this caching like this, why don't we code
> up some iterators that we can loop over to fetch the required EMs.
Thank you very much for your quick reply and for sharing your idea
with code. I also think
On Fri, 26 Aug 2022 at 12:40, Yuya Watari wrote:
> This performance degradation is due to the heavy processing of the
> get_ec***_indexes***() functions. These functions are the core part of
> the optimization we are working on in this thread, but they are
> relatively heavy when the number of par
esOn Tue, 9 Aug 2022 at 19:10, David Rowley wrote:
> I've not had a chance to look at the 0003 patch yet.
I've looked at the 0003 patch now.
The performance numbers look quite impressive, however, there were a
few things about the patch that I struggled to figure what they were
done the way you
On Mon, 8 Aug 2022 at 23:28, Yuya Watari wrote:
> If you have already applied David's patch, please start the 'git am'
> command from 0002-Fix-bugs.patch. All regression tests passed with
> this patch on my environment.
Thanks for fixing those scope bugs.
In regards to the 0002 patch, you have;
1 - 100 of 109 matches
Mail list logo
