Time |
Nick |
Message |
03:17 |
|
sandbergja joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:00 |
|
agoben joined #evergreen |
07:37 |
|
collum joined #evergreen |
07:58 |
|
StomproJ joined #evergreen |
08:17 |
|
rfrasur joined #evergreen |
08:36 |
|
mmorgan joined #evergreen |
08:39 |
|
dbwells joined #evergreen |
08:43 |
|
Dyrcona joined #evergreen |
08:53 |
|
rjackson_isl joined #evergreen |
09:00 |
|
mantis1 joined #evergreen |
09:21 |
|
jvwoolf joined #evergreen |
09:25 |
|
Stompro joined #evergreen |
09:58 |
|
sandbergja joined #evergreen |
10:03 |
|
mmorgan1 joined #evergreen |
10:25 |
bshum |
Hmm, latest master has an unstamped upgrade script hanging around |
10:26 |
bshum |
bug 1849736 |
10:26 |
pinesol |
Launchpad bug 1849736 in Evergreen "Add action trigger for email/sms for patron self registration" [Wishlist,Fix committed] https://launchpad.net/bugs/1849736 |
10:29 |
|
gmcharlt joined #evergreen |
10:30 |
Dyrcona |
Well, "delete from asset.call_number_suffix ...." is slow. |
10:31 |
bshum |
Define "slow" :D |
10:32 |
Dyrcona |
Over 75 minutes to not delete 10,194 entries... I stopped it to see what's going on. |
10:33 |
Dyrcona |
The cancel request output shows this, which is not from Evergreen or my code, so must be some fkey thing: SELECT 1 FROM ONLY "asset"."call_number" x WHERE $1 OPERATOR(pg_catalog.=) "suffix" FOR KEY SHARE OF x |
10:34 |
|
khuckins joined #evergreen |
10:34 |
Dyrcona |
Thing I'll try the owning_lib that only has 262 and see what the plan looks like. |
10:34 |
Dyrcona |
s/Thing/Think/ |
10:48 |
|
mmorgan joined #evergreen |
10:48 |
Dyrcona |
hmm... Doens't look like it should be all that slow: https://pastebin.com/NXqu59Qa |
10:48 |
Dyrcona |
But, I don't really understand explain output. |
10:51 |
Dyrcona |
What I ran: https://pastebin.com/GuCTRb6f |
10:52 |
|
terranm joined #evergreen |
10:55 |
jeff |
Dyrcona: when running one of the "slow" ones in a transaction, what is slow, the DELETE or the COMMIT? |
10:57 |
Dyrcona |
jeff: In a transaction, it's the commit. I'm pretty sure it's the fkey relationship on asset.call_number. I suspect maybe its doing a cartesian product for each row, maybe. |
10:57 |
JBoyer |
Dyrcona, that reminds me of bug 1778940. |
10:57 |
pinesol |
Launchpad bug 1778940 in Evergreen 3.2 "Indexes needed on A/T event output fields" [Medium,Fix released] https://launchpad.net/bugs/1778940 |
10:58 |
JBoyer |
an index on acn.prefix/suffix may help if so. |
10:58 |
terranm |
miker: did I do the signoff for bug lp1570072 wrong? The code is at this branch - https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/lp1570072_update_hold_notifications |
10:58 |
csharp |
bshum: oops - my bad |
10:58 |
jeff |
you can probably create temporary indexes and use SET CONSTRAINTS ALL IMMEDIATE; to see if the delete + commit goes quickly. |
11:00 |
jeff |
for every row in asset.call_number_suffix you're deleting, postgres is going to be looking up call numbers by suffix, and will likely seq scan due to lack of index on asset.call_number.suffix |
11:00 |
mmorgan |
terranm: I think you missed cherry-picking a commit in your signoff for that bug. |
11:00 |
terranm |
Bleha |
11:00 |
terranm |
*bleah |
11:00 |
miker |
terranm: I see your signoff on the release notes commit on your signoff branch, but normally all the commits that make up the change would be added to the signoff branch, each with a modified commit message adding your name to the list. I just wanted to make sure that I was not missing the code commit mixed into other commits or something |
11:01 |
csharp |
grabbing 1199 |
11:01 |
terranm |
miker: Sorry, I thought I had cherry-picked both commits. Do you need me to redo it? |
11:02 |
miker |
terranm: no, I can pick the code and add your name, no worries |
11:02 |
terranm |
Cool, thanks! |
11:02 |
Dyrcona |
terranm: I use this for grabbing a bunch of commits at once: https://gist.github.com/Dyrcona/4629200 |
11:02 |
csharp |
bshum: berick: thanks for the heads up on the unstamped script |
11:03 |
terranm |
Dyrcona++ |
11:04 |
csharp |
Dyrcona: ooooh - I have seen this before |
11:04 |
csharp |
*haven't |
11:04 |
Dyrcona |
tsbere++ # We both wrote different versions and the final version is based more on his. |
11:04 |
csharp |
tsbere++ |
11:04 |
terranm |
tsbere++ |
11:04 |
csharp |
@karma tsbere |
11:04 |
pinesol |
csharp: Karma for "tsbere" has been increased 3 times and decreased 0 times for a total karma of 3. |
11:04 |
Dyrcona |
Did you know you can add gists as git remotes and clone them, too? |
11:04 |
pinesol |
[evergreen|Chris Sharp] LP#1849736: Stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=254ef81> |
11:05 |
csharp |
oh - right, I guess we reset karma a while back |
11:05 |
csharp |
no, I didn't know that |
11:07 |
jeff |
github gists are full-on git repos. |
11:08 |
berick |
ditto the wiki, which is quite handy |
11:09 |
Dyrcona |
jeff: you're saying that I should add an index on asset.call_number.suffix? |
11:12 |
Dyrcona |
jeff++ |
11:13 |
jeff |
I've found that kind of index to be useful in other situations, such as when purging some OU data that had foreign key constraints all over the place. I seem to recall success with creating and dropping the index within the transaction, possibly only effective when using SET CONSTRAINTS ALL IMMEDIATE. |
11:13 |
Dyrcona |
Well, I'm going to add it permanently. |
11:13 |
jeff |
(but don't quote me on the index create/drop in the transaction, I don't do it often enough to trust my memory, and I didn't have time to test just now) |
11:14 |
Dyrcona |
I created the index separately. I can do it before the transaction in the script. |
11:14 |
jeff |
I think much of the time I was using SET CONSTRAINTS ALL IMMEDIATE so that I could find the slow DELETEs out of a bunch of DELETEs before I got to COMMIT. |
11:15 |
|
alynn26_away joined #evergreen |
11:16 |
csharp |
argh - I did "mv" instead of "git mv" |
11:18 |
csharp |
csharp-- |
11:19 |
pinesol |
[evergreen|Chris Sharp] LP#1849736: remove testing upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ed4b678> |
11:22 |
berick |
csharp++ # fixing |
11:35 |
pinesol |
[evergreen|Cesar Velez] LP#1570072: update hold notification methods upon preference changes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e92293> |
11:35 |
pinesol |
[evergreen|Galen Charlton] LP#1570072: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb6050e> |
11:35 |
mmorgan |
terranm++ |
11:35 |
mmorgan |
miker++ |
11:41 |
rfrasur |
terranm++ |
11:42 |
rfrasur |
miker++ |
11:42 |
|
nfBurton joined #evergreen |
12:36 |
|
jihpringle joined #evergreen |
12:44 |
|
sandbergja joined #evergreen |
12:46 |
|
tlittle joined #evergreen |
14:33 |
|
nfBurton joined #evergreen |
15:11 |
|
khuckins joined #evergreen |
15:47 |
|
mantis1 left #evergreen |
17:08 |
|
jvwoolf left #evergreen |
17:08 |
|
mmorgan left #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
20:25 |
|
sandbergja joined #evergreen |
21:57 |
|
sandbergja joined #evergreen |
22:57 |
|
sandbergja joined #evergreen |
23:01 |
|
sandbergja joined #evergreen |
23:16 |
|
sandbergja joined #evergreen |
23:40 |
|
sandbergja joined #evergreen |