From gulleymaalik at gmail.com  Sat Sep  3 22:02:48 2016
From: gulleymaalik at gmail.com (maalik gulley)
Date: Sat, 03 Sep 2016 22:02:48 +0000
Subject: Meeting notes for April
In-Reply-To: <20160502153632.GA2335@orient>
References: <1bKdnThYpNCFrL_KnZ2dnUU7-I3NnZ2d@mozilla.org> <otGdnXAFYcsBSb7KnZ2dnUU7-d2dnZ2d@mozilla.org>
 <mailman.1118.1462051136.24194.dev-apps-bugzilla@lists.mozilla.org>
 <VeOdnfz8LKZ2wrrKnZ2dnUU7-eednZ2d@mozilla.org> <20160502153632.GA2335@orient>
Message-ID: <CACCyM88UPJOPe_zmSa2mru_q9EYacRCkbhzFQpaEtyqB+t4iRA@mail.gmail.com>

Stop all malware and Bugzilla

On Mon, May 2, 2016, 11:37 AM Emmanuel Seyman <emmanuel at seyman.fr> wrote:

> * Gervase Markham [02/05/2016 15:10] :
> >
> > From my perspective (others may disagree) it's not impossible that we
> > host it another Git-hosting site and do a read-only mirror on Github
> > (for visibility), if sufficient contributing developers object on
> > principle to Github and can agree on an alternative site with a
> > reasonable feature set.
>
> FYI, the terms of service you have to agree to in order to create an
> account in github are here:
> https://help.github.com/articles/github-terms-of-service/
>
> And the privacy policy is here:
> https://help.github.com/articles/github-privacy-policy/
>
> >                         However, given our limited resources, I don't
> > believe self-hosting would be a good use of them.
>
> A while back, there was talk of being hosted by the Eclipse Foundation.
> Would they be willing to maintain a git system (assuming they don't
> already do that)?
>
> Emmanuel
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=gulleymaalik at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20160903/45694866/attachment.html>

From jfearn at redhat.com  Tue Sep  6 07:08:40 2016
From: jfearn at redhat.com (Jeff Fearn)
Date: Tue, 6 Sep 2016 17:08:40 +1000
Subject: RFC pod2rst docs changes
Message-ID: <07d5295d-9f83-ed21-01ba-380cdbc63c84@redhat.com>

Hi, using RST bugs me and having the docs split between two UIs bugs me,
the solution, pod2rst.

Attached is a patch to replace the current pod2html with pod2rst, it's
incomplete as I'm not sure exactly where to put the rst files or how
best to integrate the docs in to the rest of the ... rest :D

Currently they get put in to docs/$lang/intergration/api/ and get added
to the bottom of the integrating docs.

https://jfearn.fedorapeople.org/bz5-docs-test/integrating/index.html

Note the poor choice of title for this section ^_^

I copied a couple of extensions in to the upstream 5.0 branch just for
demonstration.

I note that none of the extensions get added to the search, going to
have to figure that one out.

It'd be nice to put the WebServer docs in to the API docs, but should
they go in both places?

It's also be nice if we had a standard way of doing User and admin docs
in the extension pod, and putting that in the right guide.

Say Extension.pm has the user docs and lib/Config.pm has the admin docs,
or something.

What I like about that is all the information would be available both in
the POD and in the web docs, so you could always find all the docs.

Comments welcome ;)

Cheers, Jeff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pod2rst.patch
Type: text/x-patch
Size: 4887 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20160906/52f5a4af/attachment.bin>

From jfearn at redhat.com  Wed Sep  7 01:11:20 2016
From: jfearn at redhat.com (Jeff Fearn)
Date: Wed, 7 Sep 2016 11:11:20 +1000
Subject: RFC pod2rst docs changes
In-Reply-To: <07d5295d-9f83-ed21-01ba-380cdbc63c84@redhat.com>
References: <07d5295d-9f83-ed21-01ba-380cdbc63c84@redhat.com>
Message-ID: <15108053-8796-ff05-dd13-8b406628d7a4@redhat.com>

On 6/09/2016 17:08, Jeff Fearn wrote:
> Hi, using RST bugs me and having the docs split between two UIs bugs me,
> the solution, pod2rst.
> 
> Attached is a patch to replace the current pod2html with pod2rst, it's
> incomplete as I'm not sure exactly where to put the rst files or how
> best to integrate the docs in to the rest of the ... rest :D
> 
> Currently they get put in to docs/$lang/intergration/api/ and get added
> to the bottom of the integrating docs.
> 
> https://jfearn.fedorapeople.org/bz5-docs-test/integrating/index.html
> 
> Note the poor choice of title for this section ^_^
> 
> I copied a couple of extensions in to the upstream 5.0 branch just for
> demonstration.
> 
> I note that none of the extensions get added to the search, going to
> have to figure that one out.
> 
> It'd be nice to put the WebServer docs in to the API docs, but should
> they go in both places?
> 
> It's also be nice if we had a standard way of doing User and admin docs
> in the extension pod, and putting that in the right guide.
> 
> Say Extension.pm has the user docs and lib/Config.pm has the admin docs,
> or something.
> 
> What I like about that is all the information would be available both in
> the POD and in the web docs, so you could always find all the docs.
> 
> Comments welcome ;)
> 
> Cheers, Jeff.
> 

A dingo ate my patch :(

https://jfearn.fedorapeople.org/bz5-docs-test/docs.patch

Cheers, Jeff.



From dylan at mozilla.com  Tue Sep  6 14:08:31 2016
From: dylan at mozilla.com (Dylan Hardison)
Date: Tue, 6 Sep 2016 10:08:31 -0400
Subject: RFC pod2rst docs changes
In-Reply-To: <07d5295d-9f83-ed21-01ba-380cdbc63c84@redhat.com>
References: <07d5295d-9f83-ed21-01ba-380cdbc63c84@redhat.com>
Message-ID: <ACF860EC-B2B2-4872-9004-925B1B0E56B1@mozilla.com>


> On Sep 6, 2016, at 03:08, Jeff Fearn <jfearn at redhat.com> wrote:
> 
> Hi, using RST bugs me and having the docs split between two UIs bugs me,
> the solution, pod2rst.
> 

rst for *user* facing documentation is pleasant enough (to write, at least).


> Note the poor choice of title for this section ^_^
Integration is the right section, perhaps the title should be "Bugzilla Internals".


> I copied a couple of extensions in to the upstream 5.0 branch just for
> demonstration.
> 
> I note that none of the extensions get added to the search, going to
> have to figure that one out.
> 
> It'd be nice to put the WebServer docs in to the API docs, but should
> they go in both places?
> 
> It's also be nice if we had a standard way of doing User and admin docs
> in the extension pod, and putting that in the right guide.
> 
I think user and admin docs should be in rst, even for extensions. But we can discuss this more.

> What I like about that is all the information would be available both in
> the POD and in the web docs, so you could always find all the docs.

when you say "all the docs" you mean "all the internal API stuff will be in both places",
right? The user documentation is solely in rst format and that's not going to change.
C?dric would flip a table if we changed the doc format again. :-)

I think this is a good direction, ensuring that the perl internals end up being equally accessible in either format.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2290 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20160906/649ae92d/attachment.p7s>

From vardantinyan at yahoo.com  Wed Sep  7 16:45:45 2016
From: vardantinyan at yahoo.com (Vard Antinyan)
Date: Wed, 7 Sep 2016 16:45:45 +0000 (UTC)
Subject: Code complexity survey
References: <928423465.453639.1473266745131.ref@mail.yahoo.com>
Message-ID: <928423465.453639.1473266745131@mail.yahoo.com>

Dear developers,


?
We have undertaken a task to assess code complexitytriggers and generate recommendations for developing simple and understandablecode. Our intension is to share the results with software developers of theentire world (open source, academy, industry, students), so everyone can learnthe triggers behind complex software.


?
A previous survey that we conducted with seven largecompanies have shown results that can significantly increase our understandingof complexity and empower us to manage complexity effectively.

You are welcome to learn the results of the previousstudy through this link:

https://www.facebook.com/SoftwareCodeQuality/photos/?tab=album&album_id=1639816749664288


?
However we need your help for more input and morerigorous results. My request to you is - would you please consider to answerthe questions of this survey, which takes about 10 minutes to fulfill?

https://goo.gl/forms/h9WXZ8VSEw7BUyHg1


?
The results will be shared in a public webpage andeveryone possible will be invited to learn and discuss them.


?
Your knowledge and experience is vital for achieving substantialand generalizable results, and your effort is much appreciated!


?
Sincerely

Vard Antinyan

PhD candidate in University of Gothenburg, Sweden

Tel: 0046317725707

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla

From saipraneeth.dev at gmail.com  Sat Sep 10 18:51:06 2016
From: saipraneeth.dev at gmail.com (Saipraneeth Muddana)
Date: Sun, 11 Sep 2016 00:21:06 +0530
Subject: Self-Introduction: Sai Praneeth M
Message-ID: <CAAqza-SNe+YDJZg=Q59i1oL1PLuSTwjtF2U+WiV64GSVBF0c_w@mail.gmail.com>

Hi,
This is my introduction mail to bugzilla developer mailing list and though
of contributing something to mozilla group.

   - Full legal name : Sai Praneeth M
   - IRC nick on irc.mozilla.org : msp
   - City, Country; IST
   - What do you want to help out with? Coding
   - Historical qualifications : I have done my postgraduate from IIT
   Madras and working as Engineer.

Regards,

-msp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20160911/a511b80d/attachment.html>

From gerv at mozilla.org  Mon Sep 12 14:37:02 2016
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 12 Sep 2016 15:37:02 +0100
Subject: RFC pod2rst docs changes
In-Reply-To: <mailman.2830.1473145735.18164.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.2830.1473145735.18164.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <RqqdnQSs8q8TIEvKnZ2dnUU7-VudnZ2d@mozilla.org>

On 06/09/16 08:08, Jeff Fearn wrote:
> Attached is a patch to replace the current pod2html with pod2rst, it's
> incomplete as I'm not sure exactly where to put the rst files or how
> best to integrate the docs in to the rest of the ... rest :D

Still, this is an awesome idea. Thank you for doing it!

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From dylan at mozilla.com  Mon Sep 26 02:46:35 2016
From: dylan at mozilla.com (Dylan Hardison)
Date: Sun, 25 Sep 2016 22:46:35 -0400
Subject: Towards faster keyword searches
Message-ID: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com>

When you have a keyword on 50,000+ bugs it means you're building a sql query with a 50,000 list in the form of IN (50,000 ids).
This is gets close to the limits mysql has on queries, at least and it's pretty slow.

There are a whole class of these -- anything that is a 'multiselect' type search. I believe someone suggested embedding these queries (at least as an option)
as a sub select and in general I think that's a good idea. An even nicer idea is to just let elastic search do the searching.
One of these approaches I hope to explore with an outreachy intern.

However, for the moment I really need keyword searches to be fast, so I started looking at the search code[1].
I started at the problem backwards -- first by looking at where we build search objects (the tree-like Bugzilla::Search::Clause::* stuff).
For searches with a single keyword search, I thought it would be nice to turn that into a join.

Then I wrote that, and it appears the code I wrote actually works generally for multiple keywords (although you then start wondering what the max number of joins is.)

Anyway, it's not finished code but it does work on a test install.

It's in a github branch: https://github.com/dylanwh/bugzilla/tree/fast-keywords,
you can look at the diff here: https://github.com/dylanwh/bugzilla/commit/e88bdf7168c6723d9930bc771ea93c93c3dec6b0

I will be polishing this up for a review, but I wanted to have other people look at it first.

Here's an example of a query it builds, for single_keyword=batman AND single_keyword:frog

SELECT bugs.bug_id AS bug_id, bugs.priority AS priority, bugs.bug_severity AS bug_severity
  FROM bugs
LEFT JOIN bug_group_map AS security_map ON bugs.bug_id = security_map.bug_id
LEFT JOIN cc AS security_cc ON bugs.bug_id = security_cc.bug_id AND security_cc.who = 1
INNER JOIN priority AS map_priority ON bugs.priority = map_priority.value
INNER JOIN bug_severity AS map_bug_severity ON bugs.bug_severity = map_bug_severity.value
LEFT JOIN keywords AS keywords_1 ON bugs.bug_id = keywords_1.bug_id
LEFT JOIN keyworddefs AS keyworddefs_1 ON keywords_1.keywordid = keyworddefs_1.id
LEFT JOIN keywords AS keywords_2 ON bugs.bug_id = keywords_2.bug_id
LEFT JOIN keyworddefs AS keyworddefs_2 ON keywords_2.keywordid = keyworddefs_2.id
 WHERE bugs.creation_ts IS NOT NULL
   AND ( (security_map.group_id IS NULL OR security_map.group_id IN (1,10,11,14,12,13,9,4,8,5,6,7,3,2))
        OR (bugs.reporter_accessible = 1 AND bugs.reporter = 1)
        OR (bugs.cclist_accessible = 1 AND security_cc.who IS NOT NULL)
        OR bugs.assigned_to = 1
)
   AND  bugs.resolution IN ('')  AND keyworddefs_1.name = 'batman' AND INSTR(keyworddefs_2.name, 'frog') = 0
GROUP BY bugs.bug_id
ORDER BY map_priority.sortkey, map_priority.value, map_bug_severity.sortkey, map_bug_severity.value
LIMIT 500

From jfearn at redhat.com  Mon Sep 26 03:51:38 2016
From: jfearn at redhat.com (Jeff Fearn)
Date: Mon, 26 Sep 2016 13:51:38 +1000
Subject: Towards faster keyword searches
In-Reply-To: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com>
References: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com>
Message-ID: <fa99a66e-293e-9c13-2d47-3d7e3f8b36d4@redhat.com>

On 26/09/2016 12:46, Dylan Hardison wrote:
> When you have a keyword on 50,000+ bugs it means you're building a sql query with a 50,000 list in the form of IN (50,000 ids).
> This is gets close to the limits mysql has on queries, at least and it's pretty slow.

Not only that, when you get to 65K you hit parameter limits in DBD::Pg :(

I've just had to fix a bug for this related to viewing bugs in a group.
I solved it by replacing the use of new_from_list with new_from_where
which takes the SQL used to generate the bug id list and uses it in the
query.

https://jfearn.fedorapeople.org/65KBugsInAGroup.patch

I'm not very happy with it because it requires you knowing exactly how
the sql will be used and coupling is bad, mmmk.

A more general approach to doing sub-selects instead of ID lists would
be great.

> There are a whole class of these -- anything that is a 'multiselect' type search. I believe someone suggested embedding these queries (at least as an option)
> as a sub select and in general I think that's a good idea. An even nicer idea is to just let elastic search do the searching.
> One of these approaches I hope to explore with an outreachy intern.

The effect of using ID lists instead of sub selects is wider than just
searching, as the above patch demonstrates.

> However, for the moment I really need keyword searches to be fast, so I started looking at the search code[1].
> I started at the problem backwards -- first by looking at where we build search objects (the tree-like Bugzilla::Search::Clause::* stuff).
> For searches with a single keyword search, I thought it would be nice to turn that into a join.
> 
> Then I wrote that, and it appears the code I wrote actually works generally for multiple keywords (although you then start wondering what the max number of joins is.)
> 
> Anyway, it's not finished code but it does work on a test install.
> 
> It's in a github branch: https://github.com/dylanwh/bugzilla/tree/fast-keywords,
> you can look at the diff here: https://github.com/dylanwh/bugzilla/commit/e88bdf7168c6723d9930bc771ea93c93c3dec6b0
> 
> I will be polishing this up for a review, but I wanted to have other people look at it first.
> 
> Here's an example of a query it builds, for single_keyword=batman AND single_keyword:frog
> 
> SELECT bugs.bug_id AS bug_id, bugs.priority AS priority, bugs.bug_severity AS bug_severity
>   FROM bugs
> LEFT JOIN bug_group_map AS security_map ON bugs.bug_id = security_map.bug_id
> LEFT JOIN cc AS security_cc ON bugs.bug_id = security_cc.bug_id AND security_cc.who = 1
> INNER JOIN priority AS map_priority ON bugs.priority = map_priority.value
> INNER JOIN bug_severity AS map_bug_severity ON bugs.bug_severity = map_bug_severity.value
> LEFT JOIN keywords AS keywords_1 ON bugs.bug_id = keywords_1.bug_id
> LEFT JOIN keyworddefs AS keyworddefs_1 ON keywords_1.keywordid = keyworddefs_1.id
> LEFT JOIN keywords AS keywords_2 ON bugs.bug_id = keywords_2.bug_id
> LEFT JOIN keyworddefs AS keyworddefs_2 ON keywords_2.keywordid = keyworddefs_2.id
>  WHERE bugs.creation_ts IS NOT NULL
>    AND ( (security_map.group_id IS NULL OR security_map.group_id IN (1,10,11,14,12,13,9,4,8,5,6,7,3,2))
>         OR (bugs.reporter_accessible = 1 AND bugs.reporter = 1)
>         OR (bugs.cclist_accessible = 1 AND security_cc.who IS NOT NULL)
>         OR bugs.assigned_to = 1
> )
>    AND  bugs.resolution IN ('')  AND keyworddefs_1.name = 'batman' AND INSTR(keyworddefs_2.name, 'frog') = 0
> GROUP BY bugs.bug_id
> ORDER BY map_priority.sortkey, map_priority.value, map_bug_severity.sortkey, map_bug_severity.value
> LIMIT 500-
> To view or change your list settings, click here:
> <https://lists.bugzilla.org/cgi-bin/mj_wwwusr?user=jfearn at redhat.com>
> 

I ran this on a copy of our DB and it seems to perform well. I did have
to chop off the order by as it's not leagl in Pg to have a group by
clause and then order by things not in the group by clause or an
aggregate function.

Cheers, Jeff.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20160926/a65cec90/attachment.sig>

From dylan at mozilla.com  Mon Sep 26 04:05:13 2016
From: dylan at mozilla.com (Dylan Hardison)
Date: Mon, 26 Sep 2016 00:05:13 -0400
Subject: Towards faster keyword searches
In-Reply-To: <fa99a66e-293e-9c13-2d47-3d7e3f8b36d4@redhat.com>
References: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com> <fa99a66e-293e-9c13-2d47-3d7e3f8b36d4@redhat.com>
Message-ID: <6785CD15-0EF0-423E-8041-4A8F69414920@mozilla.com>


> On Sep 25, 2016, at 23:51, Jeff Fearn <jfearn at redhat.com> wrote:
> 
>> There are a whole class of these -- anything that is a 'multiselect' type search. I believe someone suggested embedding these queries (at least as an option)
>> as a sub select and in general I think that's a good idea. An even nicer idea is to just let elastic search do the searching.
>> One of these approaches I hope to explore with an outreachy intern.
> 
> The effect of using ID lists instead of sub selects is wider than just
> searching, as the above patch demonstrates.
> 
Noted :-)


> 
> I ran this on a copy of our DB and it seems to perform well. I did have
> to chop off the order by as it's not leagl in Pg to have a group by
> clause and then order by things not in the group by clause or an
> aggregate function.

I would hope that offending code is only generated by the (mysql) parts of Bugzilla::DB::*. I'll verify that before getting that ready for review.

From lindsay at arista.com  Mon Sep 26 20:55:35 2016
From: lindsay at arista.com (Donald Lindsay)
Date: Mon, 26 Sep 2016 13:55:35 -0700
Subject: Towards faster keyword searches
In-Reply-To: <6785CD15-0EF0-423E-8041-4A8F69414920@mozilla.com>
References: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com>
 <fa99a66e-293e-9c13-2d47-3d7e3f8b36d4@redhat.com> <6785CD15-0EF0-423E-8041-4A8F69414920@mozilla.com>
Message-ID: <CAGG7y8Em5nP=B5aa9-rvXFWk6TjP2ypLO9onP7p50K5cmBhFZA@mail.gmail.com>

Here are two examples of IN lists, that I see in our MySQL slow-query log:

DELETE FROM `dist_abuild_rpm` WHERE `abuild_id` IN (1370624,
1315692, 1315697, 1315705, 1315708, 1315709, 1315718,
1315718,1315723, 1315735, 1315747, 1315751, 1315752,
1315768, 1315774, 1315784, 1315834, 791557, 1315865,
1355269, 1370631, 1315894, 1315922, 1315955, 1315981,
1315999, 1377469, 1316063, 1316170, 1355324, 1316209,
1316213, 1355329, 1316240, 1316248, 1355332, 1316262,
1316272, 1316281, 791998, 1316290, 792008, 1316304,
792017, 792019, 1355344, 1316331, 1316348, 792062, 792072,
1316371, 792093, 1316384, 792100, 792117, 792119, 1316413,
1316414, 792130, 792132, 792133, 1316427, 1316448, 792162,
792187, 792201, 792203, 1316512, 1316535, 1316536, 792256,
792260, 792266, 792275, 792282, 792288, 1355387, 792293,
792296, 792308, 792319, 792323, 792324, 792338, 792345,
792350, 792359, 1316649, 792366, 792375, 792377, 1316671,
792393, 792397, 792415, 1363507, 1355411, 792444, 1316738,
1355414, 792455);


SELECT AutoTest.dut.dutspec as dutspec, propertyName,
value, startTime, endTime FROM rdam.dut
JOIN rdam.dut_property on dut_id=rdam.dut.id
JOIN AutoTest.dut ON AutoTest.dut.dutspec
LIKE CONCAT( '%', rdam.dut.name ) WHERE AutoTest.dut.dutspec
IN ( 'rdam://ck414', 'rdam://ck417', 'rdam://in343',
'rdam://ck411', 'rdam://ckp302', 'rdam://ol391',
'rdam://ckp203', 'rdam://in351', 'rdam://hs209',
'rdam://yr306', 'rdam://hs211', 'rdam://hs228',
'rdam://up486', 'rdam://hs207', 'rdam://snp104',
'rdam://hs205', 'rdam://snp105', 'rdam://ckp329',
'rdam://ckp304', 'rdam://nv443', 'rdam://ckp201',
'rdam://ckp323', 'rdam://ckp320', 'rdam://cd273',
'rdam://ckp308', 'rdam://ckp204', 'rdam://up301',
'rdam://gb305', 'rdam://nv406', 'rdam://hs106',
'rdam://fm393', 'rdam://bn102', 'rdam://fm202',
'rdam://ht103', 'rdam://in353', 'rdam://ck408',
'rdam://do411', 'rdam://do401', 'rdam://do466',
'rdam://do402', 'rdam://ol161', 'rdam://hs103',
'rdam://ckp328', 'rdam://lf327', 'rdam://ckp303',
'rdam://pts101', 'rdam://tg274', 'rdam://ckp322',
'rdam://wa401', 'rdam://hs212', 'rdam://hs214',
'rdam://lf120', 'rdam://wa444', 'rdam://ckp202',
'rdam://fm204', 'rdam://ol421', 'rdam://tg422',
'rdam://tcp106', 'rdam://yr302', 'rdam://cd343',
'rdam://cp131', 'rdam://cd369', 'rdam://psp103',
'rdam://hs112', 'rdam://psp101', 'rdam://ht238',
'rdam://lf244', 'rdam://nv210', 'rdam://in472',
'rdam://lp110', 'rdam://ht422', 'rdam://tcp105',
'rdam://in474' );

If anyone feels like speeding them up, I'm interested.

On Sun, Sep 25, 2016 at 9:05 PM, Dylan Hardison <dylan at mozilla.com> wrote:

>
> > On Sep 25, 2016, at 23:51, Jeff Fearn <jfearn at redhat.com> wrote:
> >
> >> There are a whole class of these -- anything that is a 'multiselect'
> type search. I believe someone suggested embedding these queries (at least
> as an option)
> >> as a sub select and in general I think that's a good idea. An even
> nicer idea is to just let elastic search do the searching.
> >> One of these approaches I hope to explore with an outreachy intern.
> >
> > The effect of using ID lists instead of sub selects is wider than just
> > searching, as the above patch demonstrates.
> >
> Noted :-)
>
>
> >
> > I ran this on a copy of our DB and it seems to perform well. I did have
> > to chop off the order by as it's not leagl in Pg to have a group by
> > clause and then order by things not in the group by clause or an
> > aggregate function.
>
> I would hope that offending code is only generated by the (mysql) parts of
> Bugzilla::DB::*. I'll verify that before getting that ready for review.-
> To view or change your list settings, click here:
> <https://lists.bugzilla.org/cgi-bin/mj_wwwusr?user=lindsay at arista.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20160926/48eab42d/attachment.html>

From dylan at mozilla.com  Wed Sep 28 02:56:31 2016
From: dylan at mozilla.com (Dylan Hardison)
Date: Tue, 27 Sep 2016 22:56:31 -0400
Subject: Towards faster keyword searches: Followup
In-Reply-To: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com>
References: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com>
Message-ID: <D3498F40-4206-4333-9A7E-D05A2AE28A95@mozilla.com>

I have a (still experimental) patch applied to bugzilla-dev to gauge usefulness.

https://bugzilla-dev.allizom.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&f0=OP&f1=OP&f2=keywords&f3=CP&f4=CP&f5=OP&f6=OP&f7=keywords&f8=CP&f9=CP&j1=OR&j6=OR&o2=equals&o7=equals&v2=regression&v7=intermittent-failure&list_id=725

numbers:

Total execution time: 0.087219 seconds (best)
Total execution time: 0.096627 seconds (most common)
Total execution time: 0.159978 seconds (worst)

production numbers:

Total execution time: 1.993044 seconds (best)
Total execution time: 2.047537 seconds (worst and also most common)

I think this is a keeper.



From spamsux at forgetit.org  Wed Sep 28 03:47:46 2016
From: spamsux at forgetit.org (Steve Wendt)
Date: Tue, 27 Sep 2016 20:47:46 -0700
Subject: Towards faster keyword searches
In-Reply-To: <mailman.3777.1474861919.18164.dev-apps-bugzilla@lists.mozilla.org>
References: <D821D042-2A15-424B-94EF-15A4121764C4@mozilla.com>
	<mailman.3777.1474861919.18164.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <Woidnch7Qqn_oHbKnZ2dnUU7-XOdnZ2d@mozilla.org>

> although you then start wondering  what the max number of joins is.

https://dev.mysql.com/doc/refman/5.5/en/joins-limits.html

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla