[02:49] lifeless: Around? [02:59] yes [02:59] wassup [02:59] wgrant: ^ [03:01] Was wondering if you could try https://pastebin.canonical.com/59988/ on qastaging. It takes >100ms in OOPS, but 10ms when run in psql on DF. [03:01] I wonder if person descriptions are big. [03:01] Monday's OK too :) [03:02] lifeless: ^^ [03:03] 218.988ms on wildcherry [03:04] :/ [03:04] Thanks [03:04] 100ms in explain analyze [03:04] but still ~200 when rerun as a normal query [03:04] Total runtime: 4.484 ms [03:04] (23 rows) [03:04] Time: 78.842 ms [03:04] Heh [03:04] note the startup vs exec difference - we've seen this before [03:04] Planning overhead? [03:05] IIRC it was stats access stuff [03:05] Yeah [03:05] We ran into this when we increased the stat sizes. [03:06] should be a UNION ALL [03:06] No, it shouldn't exist at all :) [03:07] yeah, 77ms to do the explain [03:07] (not explain analyze - just explain) [03:07] Right. [03:08] (this is person.administrated_teams, as called by the structural subscriptions JS to populate a form field on most structural subscription context pages) [03:08] what is this checking (my brain is to whacked to reverse engineer the meaning) [03:08] too [03:08] so, its checking tp + membership to find the admins ? [03:09] the second clause looks odd to me [03:09] ah, owned by any team the person is in [03:09] It's checking for membership in an admin or an owner [03:10] so first clause is 'in the team as an admin' and the second is '... [03:11] the sort shouldn't be there [03:11] Well [03:12] It wants a sorted list. [03:12] The issue is probably more that the query shouldn't be there. [03:12] Because I suspect that form is used on <0.1% of requests [03:13] ah, for subscribe a team ? [03:13] sure, I buy that too [03:13] And of the times that form is used, about 1% are probably for teams. [03:13] And of those, about 20% are probably not misguided :) [03:14] its the first clause that is an issue - the one with tm [03:14] 188K rows, so its now exactly huge [03:16] Should be an index scan down TP, into a 200-row read from TM, filtering down to a few rows, which then are read from person [03:17] it runs in 2.6ms [03:17] it plans in 70->140ms [03:17] Hah [03:17] Nested Loop (cost=0.00..753.27 rows=2 width=633) [03:17] -> Nested Loop (cost=0.00..748.78 rows=2 width=4) [03:17] -> Index Scan using teamparticipation_person_idx on teamparticipation (cost=0.00..147.56 rows=114 width=4) [03:18] That's a bit of worry [03:18] Index Cond: (person = 21997) [03:18] -> Index Scan using membership_person_key on teammembership (cost=0.00..5.26 rows=1 width=8) [03:18] As it touches like 4 tables. [03:18] Index Cond: (teammembership.person = teamparticipation.team) [03:18] Filter: (teammembership.status = 3) [03:18] -> Index Scan using person_pkey on person (cost=0.00..2.23 rows=1 width=633) [03:18] Index Cond: (person.id = teammembership.team) [03:18] Filter: (person.merged IS NULL) [03:18] (10 rows) [03:18] 3 [03:18] Right, that's what I would have done :) [03:19] I want 'explain explain' [03:19] Heh [03:19] Also, I want to talk to you next week about weaning SSO. [03:20] If you have time. [03:20] that would be wuverly [03:20] gotta get it on solids first [03:21] I got it mostly working on the way back from Budapest, but there are availability and performance concerns. [03:21] right [03:21] so lets talk early in the week [03:21] get me across the parameters [03:22] Yep [03:22] and I will either talk with, or setup a conf with, the sso folk [03:22] depending on $stuff, $timing etc [03:23] Thanks. [03:25] de nada :) [05:01] lifeless: Can you see any reason that person validity checks should require a search for a preferredemail, rather than having a constraint that account_status == ACTIVE => there is a preferredemail? [05:01] Trying to kill off validpersoncache and all these stupid repeated emailaddress.status == 4 queries. [06:00] uhm [06:01] do we change account_status -> inactive if the last email address gets invalidated ? [06:01] wgrant: I suspect the question needs to be put to the list; or we need to do some re-analysis; I don't have an easy answer. [06:06] lifeless: The only thing that can now cause the last email to be invalidated is deactivation/suspension. [06:06] lifeless: And those two only do it because the lack of a preferredemail is how we determine that a person is invalid. [06:15] wgrant: I think we'd want some safeguard to ensure consistent data [06:15] but I see no reason why we shouldn't trust the status field if we do that [06:15] "having a constraint that account_status == ACTIVE => there is a preferredemail" [06:15] something like that yes [06:15] a preferred validated mail [06:16] blah, youknowwhatImean [06:16] preferred => validated, but yeah === almaisan` is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [12:08] StevenK: watched cricket? :D [12:23] nigelb: No. But I saw the result. [12:30] :D :D === jelmer_ is now known as jelmer [23:08] (ht spm: http://blog.markwshead.com/1148/design-problem/) [23:13] Yay, sinzui did most of my QA [23:17] not what I expected https://launchpad.net/lca [23:45] lifeless: there's a branch of python-oops-amqp ready to be merged into trunk make release 0.0.6 (i haven't done the merge yet). but i don't have pypi permissions to create a release. is that something you can do? [23:46] wallyworld_: Can haz some QA? [23:46] sure, just getting a couple of things done [23:47] wallyworld_: whats your pypi userid ? [23:48] lifeless: wallyworld [23:48] wallyworld_: also, you need to actually merge, else trunk shows all the intermediate work. [23:48] ok [23:49] wallyworld_: added you as maintainer; should let you do it [23:49] lifeless: thank you muchly [23:49] de nada [23:49] would love a team-plugin for pypi