| lifeless | ahhhhhh | 00:25 |
|---|---|---|
| lifeless | select count(*) from bugnomination, distroseries where bugnomination.distroseries=distroseries.id and name='maverick'; | 00:26 |
| lifeless | count | 00:26 |
| lifeless | ------- | 00:26 |
| lifeless | 3329 | 00:26 |
| lifeless | 6K for lucid. Hmm | 00:26 |
| wgrant | lifeless: What's enlightening about that? | 00:31 |
| lifeless | wgrant: I had a scary moment | 00:32 |
| lifeless | wgrant: I thought the +nominations page might not be batched | 00:32 |
| lifeless | also we have nominations on debian sid | 00:33 |
| lifeless | which is more than a little bong | 00:33 |
| StevenK | lifeless: You know I found eight recipes over the weekend that reference LP branches, which is just odd | 00:33 |
| lifeless | StevenK: interesting. Do you think they are intentional or confused ? | 00:34 |
| StevenK | I think it's confusion | 00:34 |
| lifeless | win | 00:35 |
| StevenK | lifeless: https://code.launchpad.net/~launchpad-pqm/launchpad/stable/+recipes for example | 00:36 |
| wgrant | LP's policy on trusting people to not do nasty things (eg. change bug details) seems to be flawed, because an awful lot of people seem to default to clicking on everything until something happens. | 00:37 |
| lifeless | I would love a earnt-trust graduated facility | 00:39 |
| wgrant | Create recipe on a Launchpad branch -> ISP banned forever | 00:39 |
| StevenK | Haha | 00:39 |
| StevenK | They keep attempting to build, too | 00:39 |
| spm | if I may take the contrary position - if people are clicking (apparently) randomly to achieve something; that sounds like a failure to make it easy for them to figure out what they want and need; vs any issue with trust. I'd suggest further that raising barriers to doing something (trust) will only exacerbate the problem. | 00:43 |
| lifeless | spm: stackexchange is an example of graduated trust | 00:44 |
| spm | still sounds like targetting symptoms; not fixing the problem. | 00:45 |
| lifeless | spm: sometimes the problem is lack of knowledge | 00:45 |
| lifeless | spm: like driving a car | 00:46 |
| lifeless | spm: making it easier to release the brakes and accelerate to 100kmph isn't fixing the problem | 00:46 |
| lifeless | spm: I take your point, but I don't think this is an either-or situation | 00:47 |
| LPCIBot | Project db-devel build #794: FAILURE in 3 hr 20 min: https://lpci.wedontsleep.org/job/db-devel/794/ | 01:02 |
| * StevenK blinks | 01:03 | |
| StevenK | That's a little ... quick | 01:03 |
| lifeless | biab | 01:41 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | now, 1062 / 129 BugTask:+index may be a regression | 02:18 |
| lifeless | that, or something had a lock out on Bug / BugTask | 02:19 |
| jtv | hi wgrant—did I miss any further disasters? There were some distressing messages from the script after we fixed the permissions issues, but it looks like most of them had been coming out of the old script since 2006. :) | 02:20 |
| === lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 235 - 0:[#######=]:256 | ||
| lifeless | jtv: it was last night you deployed the new script right ? | 02:22 |
| jtv | yup | 02:22 |
| lifeless | jtv: does it write to the DB ? | 02:22 |
| jtv | Yes | 02:22 |
| lifeless | mmm | 02:22 |
| jtv | (Note that the only thing "deployed" in the technical sense was a cron change) | 02:23 |
| jtv | Trouble at the mill? | 02:23 |
| jtv | (Please say no) | 02:23 |
| lifeless | does it alter bug or bugtask at all ? | 02:23 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/823028 | 02:23 |
| _mup_ | Bug #823028: sudden contention on Bug/BugTask tables <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/823028 > | 02:23 |
| jtv | Can do, yes. | 02:23 |
| lifeless | jtv: yes trouble, 2000 timeouts in todays oops report | 02:23 |
| lifeless | all on bug/bugtask selects | 02:24 |
| jtv | And it's not even doing anything the old script wasn't doing. :( | 02:24 |
| lifeless | it may not be it | 02:24 |
| jtv | Well one thing it does there is close bugs. | 02:24 |
| lifeless | I'm simply starting to round up 'things thare are different' | 02:24 |
| lifeless | it may not be contention, I've retitled to remove that assumption | 02:25 |
| jtv | If transactions have become longer (which frankly I don't expect, but who knows) and the bugtask selects involve status checks… | 02:25 |
| lifeless | we've either tipped over a index bloat threshold causing a plan change to poor plans, changed a query in a poor way, or run into contention | 02:25 |
| lifeless | I think thats about the size of the option-set | 02:26 |
| jtv | Excuse me while I delete more bug spam that hit me _right after_ deleting the overnight batch, and then update my spam filters and _then_ go back to debugging akismet. :( | 02:26 |
| jtv | Nothing significant _should_ have changed w.r.t. these queries, but anything _could_. | 02:26 |
| lifeless | 2000 yesterday, 1138 the day before, 1188 the day before, 998 the day before | 02:29 |
| lifeless | ok, so its a big jump, but not as big as I thought | 02:30 |
| jtv | Back. | 02:31 |
| jtv | Still, good thing you're paying attention to it. I'm just reading up on the bug. | 02:32 |
| jtv | Count queries are nasty: lock-sensitive. | 02:33 |
| lifeless | oh? | 02:33 |
| lifeless | I didn't realise they were more lock sensitive than other selects | 02:33 |
| jtv | Well it's more that looking at them, it's so natural to expect them to be less lock-sensitive. | 02:34 |
| lifeless | they'll need to touch every page | 02:34 |
| lifeless | so if there are lots of writes I'd expect contention on the page-access-lock | 02:34 |
| jtv | That too, though thankfully postgres does no page locking. :) | 02:34 |
| lifeless | but they should be reading their mvcc-version of the pages | 02:34 |
| jtv | Oh, there's a page access lock? Didn't know that. | 02:34 |
| lifeless | http://www.postgresql.org/docs/current/static/explicit-locking.html 13.3.2 | 02:35 |
| lifeless | 'In addition to table and row locks, page-level share/exclusive locks are used to control read/write access to table pages in the shared buffer pool. These locks are released immediately after a row is fetched or updated. Application developers normally need not be concerned with page-level locks, but they are mentioned here for completeness.' | 02:35 |
| jtv | FFS SSO you know what oops I want, don't give me that stupid search page. | 02:35 |
| jtv | Well that doesn't sound like there can be any contention for them as such. | 02:36 |
| jtv | All that trouble loading up an oops page and then it renders the referrer string all across the oops text. How depressing. | 02:37 |
| lifeless | win | 02:37 |
| * jtv starts up another browser to do the same dance with | 02:37 | |
| wgrant | lifeless: The new script only appeared 11 hours into yesterday. | 02:38 |
| wgrant | When did the OOPSes start? | 02:38 |
| * wgrant checks appserver graphs. | 02:38 | |
| lifeless | it looks like midnight precisely | 02:38 |
| lifeless | and then 1200 | 02:39 |
| jtv | Ah, SSO login page, confirm a few certificates, and the unwanted search page again. | 02:39 |
| jtv | Progress. | 02:39 |
| wgrant | lifeless: Note that it only runs for ~25 minutes of each hour. | 02:40 |
| jtv | Starting at 3 minutes past the hour. | 02:40 |
| wgrant | The second half of each hour should have no publish-ftpmaster. | 02:40 |
| lifeless | sure | 02:40 |
| lifeless | the graph I'm looking at is hour granularity | 02:40 |
| wgrant | https://lpstats.canonical.com/graphs/AppServer5xxsLpnetNoRobot/20110803/20110810/ is extremely troubling. | 02:40 |
| lifeless | we'd need one that was 15m granularity to rule-out the publisher | 02:40 |
| wgrant | 2/5 through 2011-08-07, things started going bad. | 02:40 |
| jtv | Most of these seem to have happened at 22 past the hour. | 02:41 |
| jtv | Although a lot of the oops pages are giving me "500" errors. | 02:41 |
| jtv | Oh, here's one at 5:41. So that's probably not our doing. | 02:41 |
| lifeless | jtv: heh, poor liitle oops service | 02:41 |
| lifeless | and one at Aug. 8, 2011, 12:42 p.m. | 02:41 |
| jtv | It's oopsing. | 02:41 |
| jtv | Definitely a big spike at 6:22 though. | 02:42 |
| wgrant | lifeless: https://lpstats.canonical.com/graphs/AppServer5xxsLpnetNoRobot/20110809/20110810/ has the sort of granularity you are looking for. | 02:42 |
| jtv | wgrant: I don't suppose it's simply BPPH scans pushing bugtasks out of a cache? | 02:42 |
| wgrant | Not very likely. | 02:42 |
| jtv | How come? | 02:43 |
| wgrant | That hasn't changed. | 02:43 |
| jtv | Well something's changed, and we're exploring the hypothesis that it may be something in this script. | 02:44 |
| lifeless | jtv: bugtask is spectacularly hot, the linux vmcache would keep it in | 02:44 |
| wgrant | jtv: Have you looked at https://lpstats.canonical.com/graphs/AppServer5xxsLpnetNoRobot/20110803/20110810/? | 02:47 |
| wgrant | Look at the second half of the 7th. | 02:47 |
| wgrant | Something started going wrong then. | 02:47 |
| jtv | So not me then? | 02:47 |
| lifeless | I think the graph is in BST | 02:47 |
| lifeless | or vice versa | 02:47 |
| lifeless | because it has a growth at 0722 | 02:48 |
| wgrant | BST is in the graph? | 02:48 |
| wgrant | devpad is still BST, but ewww. | 02:48 |
| wgrant | Argh. | 02:49 |
| wgrant | I wish we could just get a graph of BugTask:+index timeouts. | 02:49 |
| wgrant | Let's see... | 02:49 |
| lifeless | log into the oopsdb | 02:49 |
| wgrant | Mortals cannot. | 02:50 |
| wgrant | We are restricted to obscene pipelines. | 02:50 |
| lifeless | meh, remind me tomorrow and I will rt access up for you | 02:50 |
| lifeless | we have no reason not to do that for anyone in the team that shows an interest | 02:50 |
| wgrant | Maybe. | 02:50 |
| jtv | wgrant: something else… you said the new script didn't "ls -lR" the archive. Are you quite sure? | 02:56 |
| wgrant | jtv: No, it's there. I just expected it to be in a run-parts. | 02:57 |
| jtv | Ah. No, IIRC it wasn't in quite the right place to join either of the existing run-parts dirs. | 02:58 |
| wgrant | Right, I recqall that discussion. | 02:58 |
| jtv | BTW lifeless, I notice that we still have tons of fields on bugtask that look highly mutable… do we still update those directly on the bugtask or have you changed how that works? | 03:00 |
| jtv | Heat in particular. | 03:00 |
| lifeless | jtv: no, we still have liveness headaches there | 03:05 |
| lifeless | its something we need to address | 03:05 |
| jtv | And let's be honest: I just want to see if there's something to the normal forms past Boyce-Codd after all. ☺ | 03:06 |
| lifeless | :P | 03:06 |
| jtv | In Translations I think it could make a real difference as well, not copying translationmessages around all the time just because some status flags move around. | 03:06 |
| lifeless | jtv: you mean having a separate table ? | 03:08 |
| jtv | Yes. | 03:08 |
| jtv | Would save a lot of vacuuming, I suspect. | 03:08 |
| lifeless | perhaps; plus index rewrites too | 03:09 |
| jtv | Yup. | 03:09 |
| jtv | Pretty much all the moving parts involved in updating rows. | 03:09 |
| lifeless | OTOH we can solve contention by queuing updates to non-latency-sensitive fields | 03:10 |
| jtv | This is latency-sensitive. | 03:10 |
| jtv | Also, we have a bunch of partial indexes covering those flags. | 03:11 |
| jtv | So updating one flag also searches for and updates another TM that currently holds the flag, and each of them gets taken out of one partial index and into another. | 03:11 |
| lifeless | yah | 03:11 |
| lifeless | would want to avoid hitting larger row counts of both constant-and-mutable-tables | 03:12 |
| StevenK | lifeless: Like the query of death yesterday ... | 03:12 |
| jtv | QoD? | 03:13 |
| StevenK | jtv: http://paste.ubuntu.com/660924/ and related | 03:13 |
| jtv | Oh that one | 03:14 |
| lifeless | jtv: I got it down from 25 minutes to 6 seconds | 03:14 |
| jtv | Nothing particularly mutable in there, is there? | 03:14 |
| lifeless | jtv: but not reliably | 03:14 |
| jtv | Ah, BPPH | 03:14 |
| jtv | Oh | 03:14 |
| lifeless | jtv: no, and there are bad stats involved | 03:14 |
| lifeless | jtv: the bpn->bpr relation estimates are out by a factor of 10 for %linux% | 03:15 |
| jtv | Not a dramatic difference, really, compared to what can happen. | 03:15 |
| StevenK | You underestimate just how many binary packages the linux source package builds :-) | 03:15 |
| jtv | Don't "LIKE" matches use some completely arbitrary guess? | 03:15 |
| jtv | One of those cases where a table scan is probably best... | 03:16 |
| jtv | lifeless: did you lift the BPN search out of the join and materialize it? | 03:17 |
| lifeless | jtv: yes | 03:17 |
| jtv | Good chap. | 03:17 |
| lifeless | jtv: I tried a subselect, subselect with offset 0, CTE and temp table | 03:17 |
| jtv | CTE probably does the same as temp table, perhaps with a bit less overhead? | 03:18 |
| lifeless | jtv: all the gory details are in the -ops backlog | 03:18 |
| lifeless | jtv: CTE performed much work - different plan | 03:18 |
| lifeless | bah | 03:18 |
| lifeless | temp table was < CTE was < others | 03:18 |
| jtv | Oh, the optimizer can transform through CTEs already? | 03:18 |
| lifeless | yeah | 03:18 |
| lifeless | even in 8.4 | 03:19 |
| lifeless | the temp table meant it was planning on more accurate stats | 03:19 |
| jtv | So not reliable as an optimization barrier then. Does "offset 0" still work for that? | 03:19 |
| lifeless | not sure | 03:19 |
| jtv | Anyway, I hope that we can use separation of model and storage layers as a way to free the hottest parts of our schema from the OO-style bundling of static information with mutable status. | 03:21 |
| jtv | Or look at an old pet peeve of mine: POTemplate. Quite costly to retrieve, queried all over the place for lots of reasons, and the main performance suspect is a Unicode header column that we only ever need in 2 places. | 03:23 |
| jtv | In fact maybe we should see these performance knells as a trigger for building that separate storage layer. | 03:24 |
| wgrant | Is the expense loading them, or in row width? | 03:24 |
| wgrant | If the former, we have a solution already. | 03:24 |
| wgrant | If the latter, can we force them to TOAST or something? | 03:25 |
| jtv | I'm not sure. I've never had the time to investigate it. IIRC I suspected a bit of both; certainly row width could be much much less and this is a pretty hot table. | 03:27 |
| jtv | What is the solution we have for the former? I've been angling for one for ages. | 03:27 |
| lifeless | jtv: what do you mean (for clarity) by separate storage layer ? | 03:28 |
| jtv | One thing I had in mind was "demand-loaded properties" in Storm. | 03:28 |
| wgrant | jtv: See SPR.copyright. | 03:28 |
| jtv | lifeless: what wallyworld brought up at the time — DAO | 03:28 |
| wgrant | It's a manual implementation of on-demand column loading. | 03:28 |
| wgrant | It's a bit ugly, but was a huge performance improvement. | 03:29 |
| jtv | wgrant: ah, I started doing that exact same thing with POTemplate at one point, but time pressure didn't allow me to get very far with it. | 03:29 |
| jtv | (I think TranslationMessage also has a copyright field, but it's unused) | 03:30 |
| jtv | I think lifting that sort of thing out of the table into a "rarely needed static background information" table could be even better because it also improves locality of search queries etc. | 03:30 |
| jtv | At the cost of the few places where you need the data, of course, but we have load_related/load_referencing now. | 03:31 |
| wgrant | jtv: SPR.copyright is often dozens of lines long. | 03:35 |
| wgrant | Not sure POT headers are that large. | 03:35 |
| jtv | SPR is another one of those tables that on the one hand we use all the time as a waystation in joins and the subject of searches, but on the other hand it holds lots of detailed information. And I suspect it'd break down quite neatly into a lean, hot dude and a cool, fat bloke. | 03:35 |
| jtv | Dozens of lines? You kids today have it easy. | 03:35 |
| wgrant | Most of the time all you need to know about the SPR is the ID. | 03:35 |
| wgrant | You can normally avoid joining through it at all. | 03:35 |
| wgrant | Go directly from SPPH to BPB, for example. | 03:35 |
| jtv | I don't notice those cases much, because I try not to join with tables in that way in the first place. :) But think of the cases where you need just id and spn. | 03:36 |
| jtv | In fact I was discussing this with Simon Riggs a few weeks back. | 03:36 |
| wgrant | Ah, true, often need SPN. | 03:37 |
| wgrant | But we're going to denorm that onto SPPH shortly. | 03:37 |
| jtv | Nice. | 03:37 |
| jtv | Funny how denormalizing like that is no longer a dirty word. | 03:38 |
| jtv | wgrant: while we're here… one problem we keep running into is "find the latest SPPH (or BPPH, I suppose) for a given package in a given distroseries." Would a separate cache for those buy us anything? | 03:40 |
| wgrant | jtv: Denorming SPN and BPN onto SPPH and BPPH makes that pretty much free. | 03:41 |
| wgrant | As we can have an (archive, distroseries, sourcepackagename, status) index. | 03:41 |
| wgrant | Possibly even a partial index. | 03:41 |
| jtv | But no index-only scans. | 03:41 |
| wgrant | Unless we just do (archive, distroseries, sourcepackagename, status) WHERE status in (1, 2) | 03:42 |
| jtv | But no index-only scans. | 03:46 |
| wgrant | Why not? | 03:46 |
| jtv | Because postgres doesn't do index-only scans. | 03:46 |
| lifeless | jtv: I think having an explicit mapping layer would be interesting; I also think that we'll get more bang for buck by the SOA project | 03:47 |
| wgrant | Oh, of course. | 03:47 |
| lifeless | still, having a small number of rows to actually consider is a good thing | 03:49 |
| jtv | lifeless: I suspect they're just different ways of looking at what in this specific case would be very much the same thing: properly isolate responsibility for querying and retrieving these objects, then use the elbow room afforded by that isolation to optimize storage for use. I wasn't thinking so much of a very formal layer as of a gradual extension of our development patterns to suit that optimization. | 03:50 |
| lifeless | jtv: sure | 03:51 |
| lifeless | I would, for risk management and cycle time, do either one thing : optimise storage or change the way we query | 03:52 |
| StevenK | wgrant, lifeless: I fail to see how denormalising SPN and BPN helps in this case. I need to reach for the SPR and then the BPR via the BPB anyway? | 03:55 |
| wgrant | StevenK: You can get the SPR ID from SPPH, then join directly to BPB. | 03:55 |
| wgrant | No need to join across SPR; all you need is the ID and name. | 03:56 |
| wgrant | Both of which can be on SPPH. | 03:56 |
| wgrant | SPR is pretty boring otherwise. | 03:56 |
| wgrant | A few things need the version, but that is about it. | 03:56 |
| wgrant | And by the time you want the version, you're probably already fairly selective. | 03:56 |
| wgrant | So it's OK to venture into SPR. | 03:56 |
| wgrant | As most queries are based on SPPH.status, rather than sorting by version. | 03:57 |
| lifeless | the big thing for me is that these tables have live and historic data | 03:57 |
| lifeless | I'd really like to see that partitioned | 03:57 |
| wgrant | Really partial indices and clustering should solve everything, but I guess postgres isn't quite there. | 03:57 |
| lifeless | well | 03:59 |
| lifeless | I have to disagree there | 03:59 |
| wgrant | It probably also relies on either better stats or customised plans. | 04:00 |
| lifeless | after 5 years, 10 releases, 3 current - 30% of thedata *at most* is live, 70% dead. | 04:01 |
| wgrant | And? | 04:02 |
| lifeless | 10 years, 20 releases, 3 current - 15% live | 04:02 |
| lifeless | etc | 04:02 |
| lifeless | the stats will degrade linearly | 04:02 |
| wgrant | There's no reason that has to be bad. | 04:02 |
| wgrant | It's only bad because we are relying on random stats. | 04:02 |
| wgrant | If we could dictate parts of the plan, it would be easy. | 04:02 |
| jtv | *If* we can make sure that everything we do has good locality, so that the "dead" data can sit on disk undisturbed. | 04:02 |
| wgrant | Right, we'd need clustering too. | 04:03 |
| jtv | Not necessarily, but we'd need good locality. | 04:03 |
| wgrant | All the partitioning does is adds barriers because postgres tries to be too smart. | 04:03 |
| lifeless | this is a case for temporal normal form basically - but not a date based partition, its a status based partition | 04:03 |
| lifeless | 4th?5th?6th? I forget the label. | 04:03 |
| StevenK | I wonder if SPRs exist without SPPHs | 04:34 |
| wgrant | -D cronscripts/publishing/cron.publish-ftpmaster | 04:34 |
| wgrant | Yay. | 04:34 |
| wgrant | StevenK: Yes. | 04:34 |
| wgrant | StevenK: eg. stuff that was uploaded and then rejected. | 04:34 |
| wgrant | And stuff that was the victim of DB mangling grrr. | 04:34 |
| StevenK | I'm just wondering if I work on the SPN/BPN denormalisation if it make my query not suck | 04:34 |
| wgrant | Do you have a paste of the latest version? | 04:35 |
| wgrant | Preferably with an explain analyze. | 04:35 |
| lifeless | I can grab you one from staging | 04:35 |
| StevenK | It's going to be faster than dogfood | 04:35 |
| StevenK | I'd prefer no temp tables, since this query will be used by the evilness that is pickers | 04:36 |
| wgrant | Now, the plan was to denorm the string name onto ?PPH. | 04:37 |
| lifeless | http://paste.ubuntu.com/661655/ | 04:37 |
| wgrant | Which probably means you'd need to determine the set of candidate strings from BPN, then look them up on BPPH. | 04:37 |
| wgrant | As otherwise you have a seq scan on BPPH, unless we have awesome trigram indices. | 04:37 |
| lifeless | bah, thats xringd | 04:37 |
| lifeless | I'll run linux now | 04:37 |
| StevenK | But the whole point of the SPN was so stuff isn't duplicated? | 04:37 |
| wgrant | StevenK: Is that a concern? | 04:38 |
| StevenK | It might be | 04:38 |
| wgrant | Lack of duplication without rationale is hardly something to fight to retain. | 04:38 |
| lifeless | so a %LIKE% on SPN is fast | 04:38 |
| wgrant | Sure, because the table is tiny. | 04:38 |
| lifeless | it is unlikely to be fast if the strings themselves are denormed into ?PPH | 04:38 |
| StevenK | wgrant: I daresay space saving is 'sans rationale' | 04:38 |
| lifeless | but if you put the FK onto ?PPH that should be fine | 04:39 |
| jtv | And worse than just not fast, it's impossible to estimate. | 04:39 |
| jtv | With "I'm looking for these BPNs" at least the statistics have a chance. | 04:39 |
| wgrant | lifeless: Not so long ago you were arguing thatn BPN and SPN should be abolished. | 04:39 |
| StevenK | lifeless: What about a %LIKE% across BPN? | 04:39 |
| wgrant | If you are OK with keeping FKs there, that's good. | 04:39 |
| lifeless | wgrant: yes, with trigrams or fti they should | 04:39 |
| lifeless | wgrant: these are separate discussions | 04:40 |
| wgrant | lifeless: This denorm is reasonably expensive to implement. | 04:40 |
| wgrant | We probably want some idea of where we are going to go. | 04:40 |
| lifeless | wgrant: how is it expensive? | 04:40 |
| wgrant | Mm, I guess it's not so bad if we have fastdowntime soon. | 04:40 |
| StevenK | fti across SPN simultaneously makes me happy since we can rank matches, and scared since fti is a pox | 04:41 |
| LPCIBot | Project devel build #958: FAILURE in 5 hr 40 min: https://lpci.wedontsleep.org/job/devel/958/ | 04:41 |
| jtv | FTI is a hard problem. But does it make any sense at all for package names!? | 04:43 |
| StevenK | Sure, why not? | 04:45 |
| lifeless | no stemming rules for packages | 04:45 |
| lifeless | and no substrings in the tsearch2 fti implementation | 04:46 |
| wgrant | It would be nice if we could cheaply set up a copy of a few tables from the DB to test stuff on. | 04:50 |
| StevenK | I was thinking that | 04:50 |
| lifeless | We can test on [qa]staging | 04:50 |
| lifeless | e.g. with temp tables in a transaction | 04:51 |
| lifeless | or even on the main tables if its compatible | 04:51 |
| lifeless | http://paste.ubuntu.com/661660/ | 04:52 |
| lifeless | StevenK: ^ wgrant ^ | 04:52 |
| wgrant | lifeless: What if you try a temp table of BPPHs with matching BPNs? | 04:54 |
| lifeless | boostrapping that now | 04:55 |
| lifeless | select * into temporary table test_bpph from binarypackagepublishinghistory; | 04:55 |
| wgrant | Oh, I was thinking you could just get a temp table of BPPH IDs that match the BPN query. | 04:56 |
| wgrant | Rather than duplicating a 15M row table. | 04:56 |
| * lifeless shrugs | 04:56 | |
| lifeless | may as well understand the row width impact | 04:57 |
| wgrant | I was hoping to cheaply and roughly emulate the BPPH.name index. | 04:57 |
| lifeless | EODish, I'll be doin ghouse things for a bit etc, will pop back to do the next step | 04:57 |
| wgrant | k, thanks. | 04:57 |
| lifeless | heh thats done | 04:57 |
| lifeless | now to add the column | 04:57 |
| wgrant | I guess sourcherry is a bit of a monster, even if it isn't wildcherry. | 04:58 |
| StevenK | Haha | 04:58 |
| wgrant | Particularly since it's a small table. | 04:58 |
| wgrant | s/small/narrow/ | 04:58 |
| lifeless | update test_bpph set name=binarypackagerelease.binarypackagename from binarypackagerelease where test_bpph.binarypackagerelease=binarypackagerelease.id; | 05:00 |
| lifeless | running now | 05:00 |
| lifeless | (and yes, I know I could have done this as one step | 05:00 |
| lifeless | but this has a smaller footprint - I'm betting faster overall | 05:00 |
| wgrant | In case you've not done it already, I think http://paste.ubuntu.com/661666/ is about as good as it gets. | 05:03 |
| wgrant | ie. not very, but we'll see. | 05:03 |
| wgrant | As long as it goes the right way we should be OK. | 05:03 |
| StevenK | wgrant: Didn't you want to skip over SPR entirely? | 05:04 |
| wgrant | StevenK: Can't here. | 05:05 |
| wgrant | Since SPPH isn't involved in the second query. | 05:05 |
| StevenK | Pity | 05:05 |
| wgrant | We have to go through one of them. | 05:05 |
| StevenK | wgrant: Where did 'JOIN _1 AS' come from? | 05:06 |
| wgrant | s/_1 AS // | 05:06 |
| wgrant | miscopied from lifeless' | 05:06 |
| StevenK | Sigh, I can't run it anyway | 05:07 |
| wgrant | http://paste.ubuntu.com/661675/ has the added bonus of working and being tested. | 05:10 |
| StevenK | Oh mawson? | 05:10 |
| StevenK | s/h/n/ | 05:11 |
| StevenK | Tempted to do the test_bpph shuffle there too | 05:11 |
| wgrant | On dev. | 05:11 |
| wgrant | I'm not hugely tempted to rewrite 18M rows on mawson, but maybe. | 05:12 |
| StevenK | lifeless: I wonder if that UPDATE is done yet. | 05:12 |
| StevenK | jtv: QA! | 05:16 |
| lifeless | update test_bpph set name=binarypackagerelease.binarypackagename from binarypackagerelease where test_bpph.binarypackagerelease=binarypackagerelease.id; | 05:21 |
| lifeless | UPDATE 15886099 | 05:21 |
| lifeless | Time: 884894.389 ms | 05:21 |
| lifeless | there is another approach to ths btw | 05:22 |
| lifeless | a dedicated query schema for the use case we are solving | 05:22 |
| lifeless | e.g. a fact table with spn bpn, archive | 05:22 |
| lifeless | I suspect that that would fly insanely fast and be tiny | 05:22 |
| lifeless | even if populated for the world | 05:23 |
| lifeless | will come back to that | 05:23 |
| lifeless | we will probably want some indices | 05:24 |
| StevenK | Might need distribution too, but that can probably be deduced from archive | 05:24 |
| lifeless | for your specific case we don't, but yes, we might want the schema to have it | 05:25 |
| lifeless | Seq Scan on test_bpph binarypackagepublishinghistory (cost=0.00..882508.82 rows=1272 width=12) | 05:29 |
| lifeless | so, I'll add a partial index on status, archive | 05:29 |
| wgrant | Not name too? | 05:29 |
| lifeless | sure | 05:30 |
| lifeless | create index test_bpph_archive_status on test_bpph (archive, name) where status in (1,2); | 05:32 |
| lifeless | this may take a little time | 05:32 |
| wgrant | Probably also want DAS, but we'll see. | 05:32 |
| lifeless | 30 seconds | 05:33 |
| lifeless | estimates 4000 cost now; we'll see | 05:33 |
| lifeless | wgrant: so, the reason we expec this to be better is that the active-filter is status,archive on bpph ? | 05:37 |
| jtv | StevenK: are you trying to tell me in your very personal way that one of my branches has been touched by the qa tagger? | 05:37 |
| wgrant | lifeless: Were I the planner, I would find candidate BPNs, then look up BPPHs by (archive, name, status) | 05:37 |
| StevenK | jtv: I'm trying to emulate wgrant's nagging | 05:37 |
| jtv | I could tell the difference easily. | 05:38 |
| lifeless | crap stats | 05:38 |
| lifeless | -> Bitmap Index Scan on test_bpph_archive_status (cost=0.00..1250.23 rows=792 width=0) | 05:38 |
| lifeless | Index Cond: (archive = 1) | 05:38 |
| lifeless | analyzing | 05:38 |
| lifeless | ok, now we get a sensible cost out - 900K | 05:39 |
| lifeless | its doing a hash join | 05:39 |
| jtv | Rarely good. | 05:39 |
| lifeless | forcing that off, lets see | 05:39 |
| lifeless | instant | 05:39 |
| StevenK | Hm? | 05:40 |
| lifeless | 500ms | 05:40 |
| StevenK | Nice | 05:40 |
| lifeless | thats with hash joins forced off | 05:40 |
| lifeless | I think we may have bong tuning parameters somewhere | 05:40 |
| lifeless | 12 seconds with it off, run 1 | 05:41 |
| lifeless | 11 seconds for run 2 | 05:41 |
| wgrant | Or possibly I'm better at devising plans than postgres, so it should listen :) | 05:41 |
| lifeless | wgrant: we all are when we use domain knowledge | 05:41 |
| wgrant | Exactly. | 05:41 |
| wgrant | But we can't tell it to listen. | 05:41 |
| lifeless | the trick is to figure out why pg thinks the nested loop is going to be so expensive | 05:41 |
| lifeless | the %linux% may be a cause | 05:42 |
| jtv | Well that'd do it. | 05:42 |
| lifeless | it can eliminate all names shorter than linux | 05:42 |
| jtv | As I said, there's no way to get conservative statistics on selectivity for a LIKE. | 05:42 |
| lifeless | yeah :) | 05:42 |
| wgrant | lifeless: What if you take the BPN query out into a CTE and hope it doesn't optimise through it? | 05:43 |
| lifeless | won't work | 05:43 |
| lifeless | temp table might, I'm just trying that now | 05:43 |
| jtv | Pulling the BPN ids into the client may help. | 05:43 |
| lifeless | jtv: this is roughly the same as a temp table | 05:43 |
| lifeless | jtv: though the temp table is better | 05:44 |
| wgrant | set i_am_right=true; | 05:44 |
| wgrant | Surely that will work. | 05:44 |
| StevenK | Haha | 05:44 |
| jtv | lifeless: there may be a sharp change in performance as the size of your temp table exceeds the number of common values we keep in our stats. | 05:45 |
| lifeless | jtv: yes, there can be - and passing in a big IN clause has a similar kneee | 05:45 |
| lifeless | jtv: but the knee for IN clauses is lower than that for temp tables. | 05:45 |
| lifeless | jtv: I haven't checked the code to see the why of this | 05:46 |
| jtv | That's remarkable. I would have expected the kneeee for the temp table to be dominated by our statistics config (which admittedly we've got higher than normal) and the one for the IN by projected seek costs. | 05:46 |
| lifeless | you may be right; I haven't tried to model this on different pg instances | 05:47 |
| lifeless | jtv: but IN seems to just bail somewhere in the K's of entries region | 05:47 |
| jtv | Well that may just be the sensible thing to do based on random_page_cost. | 05:47 |
| lifeless | ok, first cut with temp table was 46 ms but wrong | 05:48 |
| jtv | I think I can beat that number, if the answer doesn't have to be right. :) | 05:48 |
| jtv | TDD implementation of factorial: if n <= 1: return 1 ; else: return 6 | 05:49 |
| lifeless | ok, this works well enough | 05:49 |
| lifeless | 1341ms total time | 05:50 |
| lifeless | http://paste.ubuntu.com/661687/ | 05:50 |
| lifeless | Indexes: | 05:51 |
| lifeless | "test_bpph_archive_status" btree (archive, name) WHERE status = ANY (ARRAY[1, 2]) | 05:51 |
| lifeless | I'd like to try a fact table | 05:51 |
| StevenK | That 844 is hot? | 05:51 |
| lifeless | yes | 05:51 |
| lifeless | I was iterating on the bpn side | 05:52 |
| lifeless | so some of the spn side dropped out of cache | 05:52 |
| wgrant | (archive, distroseries, sourcepackagename, binarypackagename)? | 05:52 |
| wgrant | Might also be interesting to have overrides in there, possibly. | 05:52 |
| StevenK | lifeless: Why the OFFSET 0? | 05:53 |
| lifeless | StevenK: hacks the optimiser | 05:53 |
| jtv | Or rather, stops it from moving bits into and out of that query. | 05:54 |
| jtv | Optimization barrier. | 05:54 |
| lifeless | StevenK: forces it to optimise the subplan separately | 05:54 |
| StevenK | lifeless: You could also try the SPPH.name bit too | 05:55 |
| lifeless | the denorm? sure, after fact table + dinner | 05:56 |
| lifeless | meh, not going to do archive.purpose | 06:04 |
| lifeless | oh wow, DISTINCT + LIMIT 1 -> pointless work. | 06:07 |
| lifeless | wgrant: StevenK: this is my proposed fact table building query: | 06:07 |
| lifeless | http://paste.ubuntu.com/661693/ | 06:07 |
| StevenK | Your unbuilt assumptions are a little wonky | 06:09 |
| StevenK | A BPB will exist, it just won't link to a BPR | 06:09 |
| wgrant | Not necessarily. | 06:10 |
| StevenK | SourcePackagePublishingHistory.status IN (1, 2) -- active ; s/active/published and pending source packages/ | 06:10 |
| lifeless | sure | 06:10 |
| wgrant | active is the recognised term for that. | 06:10 |
| lifeless | close enough :) | 06:10 |
| lifeless | I ask because I get 7 rows (without the distinct) that are the same for a LIMIT 10 run of the query. | 06:11 |
| lifeless | id | archive | ds | spn | bpn | 06:11 |
| lifeless | ----+---------+----+-------+------- | 06:11 |
| lifeless | | 1 | 29 | 21221 | 61531 | 06:11 |
| lifeless | | 1 | 29 | 21221 | 61531 | 06:11 |
| lifeless | | 1 | 29 | 21221 | 61531 | 06:11 |
| lifeless | | 1 | 29 | 21221 | 61531 | 06:11 |
| lifeless | | 1 | 29 | 21221 | 61531 | 06:11 |
| lifeless | | 1 | 29 | 21221 | 61531 | 06:11 |
| lifeless | | 1 | 29 | 21221 | 61531 | 06:11 |
| lifeless | | 1 | 29 | 21238 | 61565 | 06:11 |
| wgrant | lifeless: One for each DAS? | 06:11 |
| StevenK | Per DAS would be my guess | 06:11 |
| lifeless | makes sense | 06:16 |
| lifeless | running the full mccoy : insert into spn_lookup SELECT DISTINCT sourcepackagepublishinghistory.archive,... | 06:16 |
| lifeless | bah, needed a column statement or null::int at the start. Iz off again | 06:42 |
| jtv | cjwatson: sorry for haunting you like… something that… haunts… proverbially… (examples escape me) but if you have a moment to talk about bug 659769 I may be able to resolve it for you very soon. | 07:14 |
| _mup_ | Bug #659769: should copy custom uploads to newly-initialised release <derivation> <lp-soyuz> <new-release-cycle-process> <soyuz-publish> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/659769 > | 07:14 |
| lifeless | ok, so done | 07:23 |
| lifeless | 460K rows | 07:23 |
| lifeless | 1400ms with a scan | 07:26 |
| lifeless | 550ms union with a couple of naive indices | 07:34 |
| lifeless | ah, 440 with a non broken query | 07:39 |
| lifeless | jtv: is pg smart enough to split 'foo or bar' into two separate index walks ? | 07:42 |
| jtv | lifeless: AFAIK they start out as separate nodes, and it's the optimizer that sees if they should be joined into one. So yes. | 07:43 |
| lifeless | 350ms with OFFSET 0 optimiser hacks | 07:44 |
| jtv | Why bother optimising? Just use a NoSQL database. It's web scale. | 07:45 |
| lifeless | because we want it fast now ? | 07:45 |
| jtv | Hmm I need to work on that irony. It evidently does not come across. | 07:46 |
| lifeless | 114ms in bpn scan | 07:48 |
| lifeless | 25ms in spn scan | 07:48 |
| lifeless | 16ms in spn scan to get the names out | 07:49 |
| lifeless | http://explain.depesz.com/s/P9n and http://paste.ubuntu.com/661734/ | 07:50 |
| lifeless | StevenK: ^ wgrant: ^ | 07:51 |
| stub | what is the source query you are trying to fix? | 07:54 |
| jtv | Gaaaaahhhh! Kill InitializeDistroSeries tests! Kill! Kill! | 07:55 |
| lifeless | stub: an 8? 9? table monster - sourcepackagename -> release -> publication -> distroseries + the same on the binary side | 07:55 |
| lifeless | stub: 'what source package names are currently actively published for Ubuntu and match %linux% for either the source package name or the binary package name' | 07:56 |
| stub | so select spn.name from sourcepackagename as spn, sourcepackagerelease as spr, sourcepackagepublicationhistory as spph, distroseries where spn.name like '%foo%', spr.sourcepackagename=spn.id,spph.release=spr.id,distroseries.id=spph.distroseries union the binary side? | 07:58 |
| lifeless | http://paste.ubuntu.com/661660/ | 08:00 |
| lifeless | has an experiment using a temp table as part of optimising things | 08:00 |
| lifeless | I don't have the full baseline query handy, sorry. | 08:00 |
| stub | yer - I'm after the simple (slow) form of the query. | 08:01 |
| lifeless | substitute _1 into the second query on that pastebin, and you'll have it | 08:01 |
| stub | lifeless: the distinct is unnecessary with the UNION, or perhaps leaving them in and using UNION ALL. Might help a little. | 08:10 |
| lifeless | stub: both sides can return the same SPN, so UNION is needed; the DISTINCT improves the side query even though its conceptually not needed - drops one of the intermediary table scans down by 60% | 08:11 |
| StevenK | lifeless: I quite liked the BPPH refactor results, too | 08:18 |
| lifeless | StevenK: yeh; they /might/ be generally applicable, OTOH they make that table wider and perhaps slower at other things | 08:21 |
| adeuring | good morning | 08:21 |
| mrevell | Morning | 08:26 |
| lifeless | StevenK: 320ms | 08:27 |
| lifeless | StevenK: using distinct outside and union all inside | 08:27 |
| StevenK | Is that SPPH.name, or the fact table? | 08:27 |
| lifeless | fact table | 08:27 |
| lifeless | and at that, 150ms of that time is just looking up the spn and bpn in their tables | 08:28 |
| StevenK | My concern with a fact table is how to keep the bugger up to date | 08:28 |
| lifeless | there are a few strategies; in the appserver, triggers | 08:29 |
| lifeless | it may not be worth it. It was spectacular with bugtask though | 08:29 |
| lifeless | so I thought worth testing here. | 08:30 |
| StevenK | So, based on the numbers, I think the refactoring of name into {B,S}PPH is a good deal | 08:31 |
| lifeless | there are 18000 linux package names in bpn | 08:31 |
| lifeless | only 125 are relevant | 08:31 |
| wgrant | Howso? | 08:31 |
| lifeless | if we had trigrams I'd be keen to inline it | 08:31 |
| wgrant | There should be way more than 125 relevant. | 08:32 |
| wgrant | There are thousands of Linux binary names in the primary archive. | 08:32 |
| lifeless | wgrant: the final result with all these queries has been 125 | 08:32 |
| wgrant | ah. | 08:32 |
| wgrant | Right, that's just distinct sources, of course. | 08:32 |
| lifeless | StevenK: these options aren't exclusive; can do both, or neither. | 08:33 |
| StevenK | lifeless: Sure | 08:33 |
| lifeless | StevenK: either way you have a redundancy to cater for | 08:33 |
| StevenK | lifeless: Given the numbers for queries without either, I think it's clear we have to do one or both of them | 08:34 |
| lifeless | agreed | 08:34 |
| lifeless | its probably least engineering to do just the bpph denorm | 08:34 |
| lifeless | spph isn't needed - we can get through to the spn in 300ms or so IIRC | 08:34 |
| wgrant | We can probably sensibly do the fact table in triggers, unlike bugsummary, but the name denorm is still far simpler. | 08:35 |
| lifeless | I'd consider maintain this one in appserver code - you know when you are deleting something much more accurately than a trigger would; will be faster. | 08:36 |
| wgrant | Ahahaha no. | 08:37 |
| lifeless | :) | 08:37 |
| lifeless | which reminds me | 08:37 |
| lifeless | we seem to have some skew built up or building pu in bugsummary | 08:37 |
| StevenK | bigjools: O hai -- didn't you say you were moving DF to devel? | 08:37 |
| wgrant | lifeless: That's amusing. | 08:37 |
| wgrant | And entirely unexpected, of course... | 08:38 |
| bigjools | StevenK: I'm waiting until FDT is deployed and working | 08:38 |
| lifeless | wgrant: was a risk, which we did wwhat we could to address up front | 08:38 |
| wgrant | Yay, oneiric. | 08:40 |
| wgrant | lightdm appears to not start automatically any more. | 08:40 |
| lifeless | no, thats the new version | 08:49 |
| lifeless | ultralightdm | 08:49 |
| * nigelb waves | 08:58 | |
| nigelb | hello! | 08:58 |
| wgrant | Morning nigelb. | 09:03 |
| rvba | lifeless: Hi, I'm having a look at your latest-monthly-pageids.html thing, could you send me a large zserver trace logs file for me to be able to run the script locally. (I'm sure I have access to logs somewhere but I need your help to find them) | 09:04 |
| nigelb | hello wgrant | 09:04 |
| nigelb | Working on my slow moving bug fix for tooltips today | 09:05 |
| wgrant | rvba: carob:/srv/launchpad.net-logs/lpnet/*/launchpad-trace*.log | 09:06 |
| wgrant | nigelb: How's that going? | 09:06 |
| wgrant | rvba: Today's are a gigabyte so far, however :) | 09:06 |
| nigelb | wgrant: slow, due to lack of time. | 09:07 |
| wgrant | nigelb: That's probably the best reason for it to be slow. | 09:07 |
| rvba | wgrant: Thanks! | 09:07 |
| stub | lifeless: we can get trigrams - its in pg_contrib, but we have not used it yet (tied up in all our search story). | 09:10 |
| nigelb | wgrant: I keep having to spend 5 to 10 minutes figuring out what I was trying the last time :) | 09:10 |
| wgrant | lifeless: Ah, no, it's not lightdm... someone broke i915, so it's even more amusing. | 09:12 |
| nigelb | Intel graphics is always fun. | 09:12 |
| jtv | StevenK, still here? | 09:18 |
| StevenK | jtv: Hm? | 09:18 |
| jtv | I was just wondering about may_require_job vs. multi-parent. | 09:18 |
| jtv | AFAICT may_require_job currently returns False if the derived series has any parent that's in the same distro, on the grounds that we don't track DSDs within the same distro. | 09:19 |
| jtv | But ISTM that's just a surviving workaround from the time when it didn't get passed an explicit parent series. | 09:19 |
| StevenK | I doubt that is a common case | 09:19 |
| jtv | Now that it receives both derived_series and parent_series, I suspect the check should be simply for derived_series.distribution == parent_series.distribution. | 09:20 |
| lifeless | stub: it would be interesting to see if trigrams got useful statistics for query plans | 09:35 |
| stub | where were you thinking of using them? scan of the spn/bpn didn't seem that bad compared to the rest of the query you were looking at. Thinking of keeping redundant copies of the packagename so the queries don't need to go that deep? | 09:37 |
| lifeless | stub: the query planner can't assess row counts sensibly for like '%...' queries | 09:37 |
| stub | fwiw, WITH cte's should let you avoid temporary tables. | 09:37 |
| lifeless | stub: different plans, WITH cte was 2-3 times slower than the temp table | 09:38 |
| stub | because you could create an index? | 09:38 |
| stub | I don't think trigrams will help assess row counts better. | 09:38 |
| lifeless | no, because the temp table gets fully evaluated before the plan for the next query is done | 09:39 |
| lifeless | so rather than seeing 1M rows, it sees 60K | 09:39 |
| lifeless | when it thinks the row count is higher than it will be (by factor of 10, for instance), it will switch to hash joins, or seq scans | 09:39 |
| lifeless | stub: I don't know if they do/don't. I can imagine a stats gatherer for them that will | 09:39 |
| lifeless | so, one place to use them would be for that. | 09:40 |
| lifeless | the other place, is, as you say, to inline the search term to a middle table in the query | 09:40 |
| stub | yer, but this is in contrib so I doubt that exists atm. | 09:40 |
| lifeless | however, we did a simple denorm experiment putting the bpn id onto bpph | 09:40 |
| bigjools | lifeless or stub, is my db patch ok to land and if so I presume db-devel for now? | 09:40 |
| lifeless | and that got us a 650ms query | 09:40 |
| lifeless | which is probably fine | 09:41 |
| lifeless | we can get 300ms without trigrams with a fact table | 09:41 |
| lifeless | with trigrams we could shave 100ms off that easy, I think. | 09:41 |
| poolie | did lp just lose its session cookies? | 09:41 |
| stub | no | 09:41 |
| lifeless | (because 100ms of that 300ms is the bpn scan) | 09:41 |
| poolie | oh for some reason i got an edge url from history, nm | 09:42 |
| jml | (also, LP still sends out edge URLs) | 09:42 |
| stub | lifeless: I'm just putting up a branch turning off all the launchpaddatabaserevision checks. I can't think of any sane runtime checks that will work with fastdowntime that won't bite us in the arse. | 09:43 |
| StevenK | jml: In which cases? | 09:44 |
| wgrant | stub: Isn't the current one OK? | 09:44 |
| wgrant | stub: That is, refusing to start if patches are unapplied. | 09:44 |
| stub | wgrant: Only if we never use -0 patches. | 09:44 |
| lifeless | jml: in email? yes, if someone uses edge to do an action. | 09:44 |
| wgrant | We should stop special-casing -0 patches. | 09:44 |
| wgrant | But I think the -[^0] patch rules are fine. | 09:45 |
| stub | wgrant: we have optional patches that might not be live by the time the code is updated. | 09:45 |
| lifeless | stub: all things considered, I'm +1 | 09:45 |
| wgrant | Perhaps -0 patches get the -[^0] rules, and -[^0] get no rules? | 09:45 |
| stub | wgrant: But when would you ever use -0? You can't have a required patch because the code needs to run with the currently deployed schema and the HEAD schema. | 09:47 |
| lifeless | stub: a required patch would be one that is deployed | 09:47 |
| wgrant | stub: Note the code after the patch. | 09:47 |
| wgrant | s/Note/Not/ | 09:47 |
| wgrant | A rev after the patch could reasonably expect to be running on the patch, couldn't it? | 09:48 |
| lifeless | stub: e.g. develop it in a pipeline, land the db patch to db-devel, get it deployed, then land the rest to devel | 09:48 |
| stub | So you get no benefit of the run time check, as you couldn't get that far without managing that yourself. | 09:49 |
| lifeless | sure | 09:49 |
| lifeless | which is why I'm +1, all things considered ;) just describing a scenario where it could save some headache, if someone landed on devel too soon without the db component. | 09:50 |
| lifeless | of course, merging a pipe would merge the db patch to unless special care it taken | 09:50 |
| stub | Your code can't land on devel until your patch has been merged from db-devel or your tests will fail (and if they pass, it isn't a required patch...). So it would catch someone merging db-devel without a deployment having happened. | 09:52 |
| lifeless | rvba: legend! | 09:53 |
| nigelb | stub: that's going to go into a T-shirt ;) | 09:57 |
| rvba | lifeless: ;) | 09:57 |
| lifeless | night all | 09:58 |
| nigelb | night lifeless | 09:59 |
| henninge | jtv: Hi! Do you have a few minutes for pre-imp chat? | 10:08 |
| jtv | henninge: not really, sorry! | 10:08 |
| henninge | jtv: np | 10:09 |
| allenap | gmb: Thanks for the review :) | 10:12 |
| === jtv is now known as jtv-afk | ||
| gmb | allenap: No problem :) | 10:36 |
| === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 235 - 0:[#######=]:256 | ||
| LPCIBot | Yippie, build fixed! | 10:49 |
| LPCIBot | Project db-devel build #795: FIXED in 6 hr 8 min: https://lpci.wedontsleep.org/job/db-devel/795/ | 10:49 |
| stub | gmb: An all-red MP for you: https://code.launchpad.net/~stub/launchpad/trivial/+merge/70840 | 11:06 |
| gmb | stub: \0/ | 11:06 |
| gmb | stub: Approved. | 11:07 |
| stub | ta | 11:07 |
| * gmb -> food | 11:15 | |
| danilos | mrevell, "You've got mail!" | 11:17 |
| * danilos -> food | 11:17 | |
| mrevell | thanks danilos | 11:42 |
| === stub1 is now known as stub | ||
| gary_poster | allenap, for your Dict, I imagine you already thought about wrapping an object (so that the dict API operates on the inner, "clean" object). Just sharing a thought I had while reading mail. :-) | 11:54 |
| * henninge lunches | 11:54 | |
| === henninge is now known as henninge-lunch | ||
| === Ursinha-afk is now known as Ursinha | ||
| deryck | Morning, all. | 12:33 |
| allenap | gary_poster: I did think about that. Unfortunately the convenience of dict.name notation is lost. Also, I think JavaScript is not quite rich enough (yet) to absorb all Python idioms, and maybe I just ought to get used to it. | 12:38 |
| gary_poster | allenap, heh, ok cool. You can also try a JS language compiler ;-) | 12:42 |
| allenap | gary_poster: Yeah, that would be pretty cool. I'd need to learn how to see the Matrix to use a debugger with it, that's the only downside :) | 12:45 |
| gary_poster | :-) | 12:45 |
| === henninge-lunch is now known as henninge | ||
| rvba | gmb: Hi and thanks for the review! Do you think I should land it as is or, like in suggest in the MP, get stub to host the jquery plugin file alongside the other stuff that the report page uses? | 13:33 |
| gmb | rvba: I got as far as "uses?" and then a little message that says "incompatible encoding". My computer may be being all English and refusing to display something... | 13:35 |
| rvba | gmb: weird ... "uses?" is the last word of my sentence ... | 13:36 |
| gmb | Huh. | 13:36 |
| gmb | Odd | 13:36 |
| StevenK | "think I�should" is what I saw, so something odd is there | 13:36 |
| gmb | rvba: Anyway, I think getting stub to host the plugin is probably the canonical best-way-of-doing-things here, so let's do that. | 13:37 |
| rvba | gmb: all right. | 13:37 |
| rvba | Thanks. | 13:37 |
| gmb | np | 13:38 |
| gary_poster | allenap, I found it interesting and amusing given our earlier banter that I just heard of this in a mailing list: http://www.infoq.com/news/2011/08/debug-languages-on-javascript-vm (would allow mapping debugging through compiled languages, and compressed JS, in Firefox and WebKit) | 13:41 |
| allenap | gary_poster: Hehe, that is awesome :) | 13:42 |
| gary_poster | :-) | 13:43 |
| cr3 | who created the images under ./lib/canonical/launchpad/images/? I'd like to ask for a similar image :) | 13:59 |
| * deryck switches offices, back online soon | 14:19 | |
| gary_poster | bac, we have this bug: "My Ubuntu Member membership recently expired. I was expecting to get a notification by email when it came due, but I didn't. I have checked my spam trap, but there's nothing there." Is that a regression or a feature request? | 15:03 |
| bac | gary_poster: i know in the past i have gotten expiration reminders. is it configurable? | 15:04 |
| gary_poster | bac, no idea, looking | 15:06 |
| bac | gary_poster: me too. | 15:06 |
| bac | gary_poster: forwarded you an email | 15:07 |
| bac | gary_poster: teammembership-email-notification.txt is a good start | 15:08 |
| bac | gary_poster: team renewal policy must be ONDEMAND | 15:08 |
| bac | gary_poster: so it is either a regression or the team is not configured as he expectes | 15:09 |
| * bac suspects the latter | 15:09 | |
| gary_poster | bac, got it, thanks. it is the ubuntu team AIUI but maybe it is loco. Do you know where I can find the ONDEMAND setting for the team in the web? I'm looking for ~yellow and have not found yet | 15:10 |
| gary_poster | Actually bac | 15:10 |
| gary_poster | I see option on +edit | 15:10 |
| gary_poster | but option starts with text "When someone's membership is about to expire, notify them and:" | 15:11 |
| gary_poster | so notification should always be sent according to that text | 15:11 |
| bac | gary_poster: yes, i suspect it is the second of that group | 15:11 |
| gary_poster | bac, you mean loco? | 15:11 |
| bac | gary_poster: no, i meant ONDEMAND probably corresponds to the second selection | 15:12 |
| bac | but you're right, it should notify based on that description in the UI | 15:12 |
| gary_poster | bac OIC. But we don't actually need ONDEMAND for the email to be sent out, right? yeah ok. So I'll maybe try to find some logs for this and see if I can find the user there...and generally emails being sent out | 15:13 |
| gary_poster | thank you bac | 15:13 |
| bac | gary_poster: yes, looking through that doc test i see the other states should also send email | 15:13 |
| gary_poster | ack | 15:14 |
| sinzui | jcsackett, do you have time to mumble? | 15:28 |
| jcsackett | sinzui: sure, just a moment. | 15:28 |
| jcsackett | sinzui: can you hear me? | 15:30 |
| jcsackett | sinzui: i just got dropped; one second. | 15:32 |
| sinzui | I saw | 15:32 |
| adeuring | gary_poster: do you know how I can get the permission to register a new release of laze.batchnavigator on PyPI? | 15:56 |
| gary_poster | adeuring probably by asking me :-) what is your PyPI user name--the same? | 15:58 |
| adeuring | gary_poster: yes | 15:58 |
| benji | gmb: can I get https://code.launchpad.net/~benji/launchpad/bug-798945/+merge/70909 into your review queue? | 16:00 |
| gmb | benji: Sure. | 16:00 |
| benji | thanks | 16:00 |
| gary_poster | adeuring, done (sorry for slow turn around, other things going on simultaneously) | 16:02 |
| adeuring | gary_poster: thanks! | 16:02 |
| gary_poster | yw | 16:02 |
| === matsubara is now known as matsubara-lunch | ||
| === beuno is now known as beuno-lunch | ||
| gmb | benji: approved | 16:16 |
| === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 235 - 0:[#######=]:256 | ||
| benji | gmb: thanks | 16:16 |
| LPCIBot | Yippie, build fixed! | 16:31 |
| LPCIBot | Project devel build #959: FIXED in 5 hr 41 min: https://lpci.wedontsleep.org/job/devel/959/ | 16:31 |
| === deryck is now known as deryck[lunch] | ||
| === matsubara-lunch is now known as matsubara | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| lifeless | morning | 19:31 |
| deryck | morning, lifeless | 19:37 |
| bac | lifeless: regarding bug 34086 and the new assignee i think you should check out https://answers.launchpad.net/launchpad/+question/167455, also by that person. | 20:45 |
| _mup_ | Bug #34086: removal of arch-all packages while there are arch-specific packages dependent on it results in uninstallable binaries <escalated> <feature> <lp-soyuz> <soyuz-publish> <Launchpad itself:In Progress by rreynoso45> < https://launchpad.net/bugs/34086 > | 20:45 |
| lifeless | bac: heh | 20:46 |
| lifeless | bac: I considered just toggling it back, but decided to be optimisting | 20:46 |
| bac | lifeless: i think with the additional data it would be best to toggle it back | 20:46 |
| lifeless | yeah, doing so | 20:46 |
| bac | chr, ftw | 20:46 |
| lifeless | thanks | 20:48 |
| === matsubara is now known as matsubara-afk | ||
| henninge | Hello! | 21:43 |
| henninge | Can somebody please review this for me? | 21:43 |
| henninge | https://code.launchpad.net/~henninge/launchpad/bug-823164-remove-translations-by/+merge/70961 | 21:43 |
| lifeless | henninge: wouldn't it be simpler for the user option parser to just store the string ? | 21:47 |
| lifeless | henninge: thats what all the other scripts do, don't they ? | 21:47 |
| henninge | lifeless: AFAIUI the reason behind this construct is that the option is validated during initialzation. | 21:48 |
| lifeless | henninge: but its means you're in a transaction before you've taken out the script lock | 21:49 |
| lifeless | henninge: this seems unwise | 21:49 |
| henninge | lifeless: hm, true | 21:49 |
| lifeless | probably harmless in this case | 21:49 |
| lifeless | but I can imagine things that do lock in the db having trouble | 21:50 |
| lifeless | anyhow, I'm fine if you want to land this | 21:51 |
| lifeless | mmm, perhaos | 21:51 |
| lifeless | acutally no | 21:51 |
| lifeless | it conflicts with the inifile-shutdown thing for scripts | 21:51 |
| lifeless | here is why: option parsing is in order supplied; until we consult the ini file (found via the config) to see whether the script can run, which means we need to know the config to be using... | 21:52 |
| lifeless | we can't be sure that the DB will even be available | 21:52 |
| lifeless | perhaps I'm wrong | 21:52 |
| henninge | lifeless: yes, it seems wiser to change that construct. | 21:54 |
| henninge | even if that is a bit more work | 21:54 |
| * henninge regrets not having had a proper pre-imp discussion as he had meant to ... | 21:55 | |
| henninge | lifeless: thanks! ;-) | 21:55 |
| lifeless | no probs! | 21:55 |
| lifeless | I'll paste this in the review for education of anyone looking at it | 21:55 |
| henninge | lifeless: cool | 21:58 |
| LPCIBot | Project db-devel build #796: FAILURE in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/796/ | 22:15 |
| sinzui | wallyworld_, http://pastebin.ubuntu.com/662245/ | 23:13 |
| StevenK | sinzui: select count(*) from sourcepackagepublishinghistory as spph join distroseries as ds on spph.distroseries = ds.id where status in (1, 2) and archive = 1 and ds.distribution = 1; => 207k | 23:38 |
| sinzui | StevenK, https://launchpad.net/ubuntu/oneiric shows only 18542 published in development. U think you should consider using distinct | 23:40 |
| lifeless | StevenK: thats all series ever | 23:55 |
| lifeless | sinzui: distinct isn't relevant, you're comparing apples and oranges. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!