| Time |
Nick |
Message |
| 03:16 |
|
dbwells joined #evergreen |
| 03:57 |
|
stephengwills joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2020-09/2020-09-09_04:00:02/test.41.html> |
| 06:45 |
|
yar joined #evergreen |
| 06:55 |
|
agoben joined #evergreen |
| 07:11 |
|
csharp joined #evergreen |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 08:04 |
|
rfrasur joined #evergreen |
| 08:07 |
|
alynn26 joined #evergreen |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:33 |
|
rlefaive joined #evergreen |
| 08:37 |
|
rlefaive joined #evergreen |
| 08:53 |
|
collum joined #evergreen |
| 09:08 |
|
collum_ joined #evergreen |
| 09:33 |
Dyrcona |
So, testing with Pg 12 on training is not going so well. I'm told that just looking up a patron with about 40 circulations is very slow, and that Lp 1845050 is back event though I've made sure that the patch is installed. |
| 09:33 |
pinesol |
Launchpad bug 1845050 in Evergreen 3.3 "reporter interface can fail to completely load" [High,Fix released] https://launchpad.net/bugs/1845050 |
| 09:34 |
Dyrcona |
Also, PHPPgAdmin needs to be reinstalled with Pg 12 libraries. |
| 09:58 |
|
nfBurton joined #evergreen |
| 10:27 |
|
mantis1 joined #evergreen |
| 10:34 |
JBoyer |
qatests failures should be taken care of with the latest master commit. |
| 10:36 |
pinesol |
[evergreen|Jason Boyer] LP1835736: Rearrange seed data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f2c3453> |
| 10:40 |
alynn26 |
We have some custom menu options that point to an outside webpage. It has a custom URL which includes the System OU of the logged in user. Something link Http://wwww.notices.com/SysteOU/index.html With the original menus we could just place a handy {{sys_ou.shortname()}} and it would fill in the SysOU. Now with Angular, menus How to I replicate that or give me a hint as to what I could use. |
| 10:40 |
|
sandbergja joined #evergreen |
| 10:56 |
berick |
alynn26: something like this https://gist.github.com/berick/e17c9e2ed5b8da474751585caf778ebd |
| 10:56 |
berick |
alynn26: then you can use {{sysOu()}} in the html template |
| 10:56 |
berick |
note it's making a big assumption about what you refer to 'system ou' |
| 10:57 |
alynn26 |
That's what I need thanks. berick |
| 10:57 |
alynn26 |
berick++ |
| 11:26 |
|
collum joined #evergreen |
| 11:49 |
|
collum_ joined #evergreen |
| 11:58 |
|
jihpringle joined #evergreen |
| 12:05 |
|
mrisher joined #evergreen |
| 12:57 |
|
dbwells joined #evergreen |
| 12:58 |
|
khuckins joined #evergreen |
| 13:44 |
|
jvwoolf joined #evergreen |
| 13:44 |
gmcharlt |
JBoyer++ |
| 13:55 |
|
sandbergja_ joined #evergreen |
| 14:37 |
sandbergja |
Antora is looking so good! |
| 14:37 |
sandbergja |
Bmagic++ |
| 14:38 |
sandbergja |
gmcharlt++ |
| 14:38 |
sandbergja |
dig++ |
| 14:48 |
Dyrcona |
I have a question for cstore query/at filter gurus. Aren't the clauses ':circ_lib" : 260' and '"-and": [ {"circ_lib" : 260} ]' basically the same? |
| 14:50 |
Dyrcona |
Well, depsite the typo of : for "..... :) |
| 14:51 |
Dyrcona |
pfft.... |
| 14:51 |
Dyrcona |
typos-- |
| 15:00 |
berick |
Dyrcona: yes i would expect those to behave the same |
| 15:00 |
berick |
ditto "circ_lib": [260] |
| 15:03 |
gmcharlt |
berick: note my update to bug 1879335 |
| 15:03 |
pinesol |
Launchpad bug 1879335 in Evergreen "Manage Authorities Angular Port" [Wishlist,New] https://launchpad.net/bugs/1879335 - Assigned to Galen Charlton (gmc) |
| 15:03 |
gmcharlt |
from my POV, upon review of the follow-ups, I'd be comfortable with it going into master by the freeze cutoff |
| 15:03 |
berick |
thanks gmcharlt, i'll take a look |
| 15:04 |
Dyrcona |
berick: Thanks. That's what I thought. I'm looking at the a/t code again to see if I can figure out why my filter doesn't seem to do what I think it should, but I think I've been working too hard today, because code that I thought I understand is making no sense to me at the moment. |
| 15:08 |
Dyrcona |
Yeah, my filter doesn't seem to be working.... |
| 15:10 |
Dyrcona |
And, I think it is the or in the query causing the problem..... |
| 15:14 |
Dyrcona |
This is acceptabl, too, isn't it: "-and" : { "-or" : [ ..... ] } . I.E. I don't [] with and.... |
| 15:15 |
* Dyrcona |
starts second guessing himself.... |
| 15:26 |
csharp |
miker: phasefx: we're testing the branch for bug 1846354 and are seeing very slow result times on this query: https://pastebin.com/Md8UfEc2 |
| 15:26 |
pinesol |
Launchpad bug 1846354 in Evergreen "wishlist: Consolidate patron notes, alerts, and messages" [Wishlist,New] https://launchpad.net/bugs/1846354 |
| 15:27 |
csharp |
I'm adding indexes hoping to help, but nothing works so far :-( |
| 15:29 |
jeff |
csharp: any chance of getting that without \x on? |
| 15:29 |
|
mantis1 left #evergreen |
| 15:31 |
phasefx |
hrmm |
| 15:32 |
jeff |
csharp: never mind! |
| 15:32 |
jeff |
https://explain.depesz.com/s/gdVL if anyone else was curious |
| 15:36 |
Dyrcona |
So, I'm trying to put a little program together to test my filter with the checkout.due hook, but I can't seem to find the code that the checkout.due hook causes to run. Anyone know where that is? I see plenty of references to the checkou.due hook, but nothing that explicitly links checkout.due with a query or part of a query. |
| 15:39 |
jeff |
Dyrcona: $hook_handlers in Open-ILS/src/support-scripts/action_trigger_runner.pl.in has the default JSON query for checkout.due, if that helps. |
| 15:40 |
csharp |
jeff++ # thanks |
| 15:41 |
phasefx |
csharp: does it help to put an index on the usr_message column on actor.usr_standing_penalty? |
| 15:41 |
Dyrcona |
jeff: Thanks! I just figured it out, though. What I was really looking for was how it determines something is due. That's done with the delay field. |
| 15:42 |
* jeff |
nods |
| 15:42 |
csharp |
phasefx: not so far |
| 15:42 |
csharp |
the paste is after adding that index, I should say |
| 15:44 |
csharp |
I'm assuming the problem is the view definition's joins? but I haven't looked super hard yet |
| 15:49 |
miker |
csharp / jeff: thanks! taking a look |
| 15:49 |
phasefx |
if I change the query from where id = '1:1' to where ausp_id = 1 and aum_id = 1, it gets rid of one of the seq scans |
| 15:50 |
* csharp |
steps away for a bit and will check back soon |
| 15:58 |
|
rhamby joined #evergreen |
| 15:58 |
miker |
phasefx: should get rid of both (if there's a significant number in both tables) |
| 16:19 |
gmcharlt |
csharp: what action is generating that query, by the way? |
| 16:42 |
csharp |
gmcharlt: uhhh - I was told by terranm that the grids for messages weren't loading and I checked the logs for obvious causes |
| 16:42 |
csharp |
I haven't looked closely yet at the UI to know what's what |
| 16:43 |
gmcharlt |
csharp: reason I'm asking is that thus far we're not seeing where a retrieval by ID is happening |
| 16:43 |
csharp |
ah - lemme check then |
| 16:46 |
csharp |
appears to be open-ils.fielder open-ils.fielder.flattened_search |
| 16:47 |
miker |
ah! I bet I know. if you enable columns that are not required, it'll request the row by id. for this, we should just make all columns "required" |
| 16:47 |
miker |
because that id is .... not really one :) |
| 16:48 |
csharp |
https://pastebin.com/RGcSi5z1 - log is truncated but hopefully provides clues |
| 16:50 |
miker |
well, my theory seems incorrect... csharp, can terran describe /how/ she got a slow UI? we can't provoke the queries that /would/ be slow |
| 16:51 |
miker |
csharp: the query posted is not looking up by id ... it should not be slow |
| 16:52 |
csharp |
miker: let me see if she can hop in here |
| 16:52 |
miker |
IOW, we know why your first query was slow, the WHERE clause was just "where id = '1234:1234'" ... but the UIs are not creating queries like that, that we can tell |
| 16:53 |
csharp |
weird |
| 16:54 |
|
terranm joined #evergreen |
| 16:54 |
* csharp |
conjures terranm |
| 16:55 |
csharp |
terranm: "csharp, can terran describe /how/ she got a slow UI? we can't provoke the queries that /would/ be slow" from miker a minute ago |
| 16:56 |
miker |
(and that first ID-based query is slow because the view constructs that as a combined "key" of two tables that could contribute to the grid, which (being computed from multiple tables) can't be indexed) |
| 16:56 |
terranm |
joining in late... there are two issues, 1) doing a patron search is acting super slow (looking up a specific barcode) and then 2) the notes/alerts are not appearing on the new Notes tab |
| 16:56 |
miker |
csharp: IOW, did you pull that first query directly from the logs, or did you pull most of it, and then adjust the where clause? |
| 16:56 |
terranm |
I do not know if the two issues are in any way related |
| 16:57 |
miker |
terranm: it's possible. you just bring up a user and go to the Notes tab, and it stalls? |
| 16:57 |
jeff |
terranm: "looking up a specific barcode" as in retrieve patron by barcode / checkout / F1, or patron search / F4 and supplying a barcode in the barcode search field? |
| 16:58 |
terranm |
No - the search itself is very slow. Like 20+ seconds to return the search result vs a 2 seconds on production |
| 16:58 |
terranm |
Going to the Notes tab, it loads immediately but then never displays anything that should be in the grid |
| 16:58 |
csharp |
miker: here's a different, also slow query: https://pastebin.com/WCFCHHaH - may be the one that corresponds with the other log message |
| 16:59 |
terranm |
jeff: going to patron search, putting a barcode in the barcode search field |
| 16:59 |
jeff |
csharp: possibly asking the obvious but: recent VACUUM ANALYZE especially if this is a newly-loaded db? |
| 16:59 |
csharp |
jeff: hmmmmmm |
| 17:00 |
miker |
csharp: thanks |
| 17:00 |
miker |
jeff: and, yes, that :) |
| 17:00 |
csharp |
pretty sure I did, I can do so again |
| 17:00 |
jeff |
(not that that would cause the unexpected lookup-by-id miker's inquiring about, but just to rule out something being slow for reasons unrelated to the notes) |
| 17:00 |
|
rfrasur joined #evergreen |
| 17:00 |
csharp |
I'll run another one (takes time, but harmless and may improve things) |
| 17:01 |
miker |
right. the lookup by aump.usr really shouldn't be slow unless you're retrieving a user with TONS of messages/penalties |
| 17:01 |
csharp |
probably worth waiting to dig too much more until that's done |
| 17:01 |
miker |
csharp: you can focus on actor.usr_message and actor.usr_standing_penalty (I think that's the name) |
| 17:02 |
csharp |
I did ANALYZE those two, but not vacuum |
| 17:02 |
jeff |
(unless the patron search is slow because of an unrelated table having bad stats) |
| 17:02 |
miker |
jeff: aye, fair |
| 17:02 |
csharp |
jeff++ # ruling out the simple |
| 17:02 |
* miker |
admits to only caring about Notes ATM :) |
| 17:03 |
jeff |
I only recently realized / observed that a patron search by barcode will match on a partial barcode. :-) |
| 17:03 |
jeff |
(unrelated, mostly) |
| 17:03 |
miker |
yeah, everything's LIKE now, I think |
| 17:03 |
csharp |
the by-ID search is still slow after the vac analyze |
| 17:03 |
csharp |
(on those two tables only) |
| 17:03 |
csharp |
I'll run a general one |
| 17:05 |
csharp |
it's moving pretty fast, so I'm thinking I did vacuum analyze before - we'll see |
| 17:05 |
terranm |
FYI, here's what I'm seeing when I open a patron with notes: https://drive.google.com/file/d/1ij7PsUTkU7SCfoKkO_aQ0C-PSJeZUZRQ/view?usp=sharing |
| 17:05 |
gmcharlt |
csharp: an explain analyze on https://pastebin.com/WCFCHHaH would be (hopefully) illuminating |
| 17:06 |
csharp |
gmcharlt: sure thing |
| 17:06 |
terranm |
There were 4 old notes/alerts/messages that had been converted and I created a new 5th one just now, and none of them appear |
| 17:06 |
rfrasur |
Hey all, I know there's basically only internal testing of the notes, but if there's anything I can do, let ping me. |
| 17:07 |
rfrasur |
s/let/just |
| 17:07 |
|
jihpringle joined #evergreen |
| 17:09 |
csharp |
gmcharlt: https://explain.depesz.com/s/84Rz |
| 17:10 |
csharp |
that's with the vacuum running, but the timing is very close to what I'm seeing in the logs |
| 17:10 |
gmcharlt |
csharp: thanks. here's an index to try: CREATE INDEX test_idx1 ON actor.usr_standing_penalty (usr_message); |
| 17:11 |
csharp |
"actor_usr_standing_penalty_usr_message_idx" btree (usr_message) - that's already there |
| 17:11 |
csharp |
(I created it as a troubleshooting measure, that is) |
| 17:13 |
gmcharlt |
ok, next please try indexes on actor.usr_message.sending_lib and actor.usr_standing_penalty.org |
| 17:13 |
csharp |
"actor_usr_standing_penalty_org_unit_idx" btree (org_unit) and "actor_usr_message_sending_lib_idx" btree (sending_lib) also already there |
| 17:14 |
csharp |
great minds! |
| 17:14 |
gmcharlt |
heh |
| 17:14 |
* csharp |
always feels awesome when he's already thought of what gmcharlt comes up with :-) |
| 17:14 |
gmcharlt |
next: the various start/set and stop date fields on those tables |
| 17:14 |
csharp |
ok |
| 17:24 |
csharp |
argh - still all seq scans - same query plan as before |
| 17:25 |
csharp |
I added actor.usr_message create_date, stop_date, read_date and ausp set_date, stop_date |
| 17:25 |
csharp |
adding aum edit_date |
| 17:26 |
miker |
csharp: could you try the query at https://pastebin.com/gPt1R4xx ? |
| 17:28 |
miker |
if that makes things happier, we may be able to give the view enough info to avoid having to change the code... |
| 17:29 |
miker |
using this: https://pastebin.com/CK2Rpn9n (note the addition to the ON clause of the JOIN) |
| 17:30 |
miker |
and, I'm called away to dinner. that view change may not be enough ... but, worth a test |
| 17:30 |
miker |
I'll check back later |
| 17:30 |
csharp |
miker: https://explain.depesz.com/s/rZwx your first edited query - I'll try the second one now |
| 17:33 |
csharp |
the original (not by-ID) query is happy now! |
| 17:33 |
gmcharlt |
great |
| 17:33 |
gmcharlt |
with any luck, that should make viewing the notes on the tab work now |
| 17:34 |
gmcharlt |
oh, but could you do the explain as well? we'll need to check whether any of the new indexes are getting used |
| 17:45 |
terranm |
I saw notes appear on one patron account once, but pulling up the same account again, they're not appearing. |
| 17:48 |
csharp |
another slow one: https://pastebin.com/QxMvL4Gn https://explain.depesz.com/s/5g18 |
| 17:48 |
csharp |
that happens when retreiving a patron by barcode |
| 17:48 |
csharp |
gmcharlt: one sec - missed your request for explain for the "good" query |
| 17:49 |
csharp |
gmcharlt: https://explain.depesz.com/s/hJGV |
| 17:50 |
csharp |
depesz++ |
| 18:00 |
pinesol |
News from qatests: Failed Building the AsciiDoc output formats <http://testing.evergreen-ils.org/~live//archive/2020-09/2020-09-09_16:00:02/test.81.html> |
| 18:01 |
gmcharlt |
csharp: thanks. looks like the additional indexes aren't being used |
| 18:10 |
|
mantis1 joined #evergreen |
| 18:10 |
|
mantis1 left #evergreen |
| 18:11 |
|
terranm joined #evergreen |
| 18:13 |
|
jvwoolf left #evergreen |
| 19:04 |
|
rlefaive joined #evergreen |
| 19:15 |
|
jihpringle joined #evergreen |
| 19:26 |
|
sandbergja joined #evergreen |
| 19:58 |
|
sandbergja joined #evergreen |
| 21:02 |
|
stephengwills left #evergreen |
| 21:07 |
|
sandbergja joined #evergreen |
| 21:26 |
|
sandbergja joined #evergreen |
| 21:29 |
|
rfrasur joined #evergreen |
| 22:00 |
|
sandbergja joined #evergreen |
| 23:36 |
|
sandbergja joined #evergreen |
