| Time |
Nick |
Message |
| 05:07 |
|
dluch joined #evergreen |
| 06:37 |
|
collum joined #evergreen |
| 07:10 |
|
kworstell-isl joined #evergreen |
| 07:19 |
|
kworstell_isl joined #evergreen |
| 07:57 |
|
BDorsey joined #evergreen |
| 08:32 |
|
jvwoolf1 joined #evergreen |
| 08:33 |
|
jvwoolf2 joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:56 |
|
dguarrac joined #evergreen |
| 09:22 |
|
Dyrcona joined #evergreen |
| 09:28 |
|
jvwoolf2 left #evergreen |
| 09:47 |
|
kworstell-isl joined #evergreen |
| 09:55 |
Dyrcona |
csharp_: I have a staff opac search timing out on Pg 14. It's running less than 7 minutes. Interestingly, the results don't seem to be cached either, but that may be the Angular staff opac. |
| 09:56 |
Dyrcona |
Patron/Bootstrap OPAC result came right back for the same search. |
| 10:07 |
|
kworstell_isl joined #evergreen |
| 10:09 |
Dyrcona |
csharp_: I'm not seeing the same slowness in the Bootstrap OPAC. |
| 10:13 |
Dyrcona |
OK. log_statement = 'all' is way too much... |
| 10:14 |
|
kworstell-isl joined #evergreen |
| 10:31 |
Dyrcona |
csharp_: I ran your query on my test db server with production data on Pg 14, and I get a different explain output: https://pastebin.com/8k1cwNZM |
| 10:32 |
Dyrcona |
Granted, it still took almost 2 minutes to run the query. |
| 10:49 |
Dyrcona |
The copy_vis_attr_cache is still the worst part of the query, even if my server used an index scan: https://explain.depesz.com/s/EBTe |
| 11:12 |
|
sleary joined #evergreen |
| 11:32 |
|
Christineb joined #evergreen |
| 11:40 |
Dyrcona |
Here's another that I ran from the Angular Staff Catalog: https://explain.depesz.com/s/Ay5y#html |
| 11:41 |
|
jihpringle joined #evergreen |
| 11:49 |
Dyrcona |
Here's that previous one on Pg10: https://explain.depesz.com/s/pCZz |
| 11:51 |
Dyrcona |
It looks like the optimizer produces quite different criteria for the vis_attr_cache join. Compare lines 53 and 54 of the former with lines 75 and 76 of the latter. |
| 12:38 |
Dyrcona |
I'm going to try Pg 11 through 13 and 15 as well. |
| 14:09 |
|
jihpringle joined #evergreen |
| 14:17 |
|
collum joined #evergreen |
| 15:05 |
|
sleary joined #evergreen |
| 15:44 |
mmorgan |
Looking at permissions for org unit closed dates, I see CREATE_ORG_UNIT_CLOSING, DELETE_ORG_UNIT_CLOSING, UPDATE_ORG_UNIT_CLOSING |
| 15:45 |
mmorgan |
I also see actor.org_unit.closed_date.create, actor.org_unit.closed_date.delete, actor.org_unit.closed_date.update. Why the different permissions? |
| 16:00 |
jeffdavis |
Looks like the all-caps ones are only used in the fieldmapper. I would guess the duplication is a primordial error that's just never been fixed. |
| 16:07 |
mmorgan |
primordial error :) |
| 16:08 |
mmorgan |
Confirmed that the lower case ones allow maintaining the closed dates. |
| 16:27 |
Dyrcona |
Yeah, the backend Perl code checks for the lower case permissions. open-il.pcrud will use the upper case perms. |
| 16:39 |
csharp_ |
Dyrcona: thanks for your additional testing - just got back from four-hour commutes yesterday/today, so it will be tomorrow before I have the wherewhital to look :-) |
| 16:43 |
Dyrcona |
csharp_: No worries. I'm waiting on the data to restore to Pg 11. |
| 16:43 |
Dyrcona |
In the meantime, I've been working on bringing our customizations up to rel_3_10. |
| 17:19 |
|
mmorgan left #evergreen |
| 19:00 |
|
JBoyer joined #evergreen |
