| Time |
Nick |
Message |
| 02:22 |
|
sleary joined #evergreen |
| 04:27 |
|
kworstell-isl joined #evergreen |
| 06:08 |
|
kworstell-isl joined #evergreen |
| 07:39 |
|
kworstell-isl joined #evergreen |
| 07:45 |
|
BDorsey joined #evergreen |
| 07:54 |
|
rfrasur joined #evergreen |
| 07:54 |
|
rfrasur joined #evergreen |
| 07:56 |
|
redavis joined #evergreen |
| 07:58 |
|
redavis joined #evergreen |
| 08:23 |
|
sleary joined #evergreen |
| 08:33 |
|
sandbergja joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 09:16 |
|
Stompro joined #evergreen |
| 09:19 |
|
Dyrcona joined #evergreen |
| 09:23 |
|
redavis joined #evergreen |
| 09:45 |
|
sleary joined #evergreen |
| 10:12 |
|
kworstell-isl joined #evergreen |
| 10:25 |
|
scottangel joined #evergreen |
| 10:25 |
|
dluch joined #evergreen |
| 10:25 |
|
Bmagic joined #evergreen |
| 11:00 |
|
briank joined #evergreen |
| 11:02 |
Stompro |
jeffdavis, "is pgbackrest significantly faster than pg_dump/pg_restore?" I was mainly interested in the incremental backup feature, so I can backup every 2 hours with a much smaller file size. |
| 11:45 |
|
kmlussier joined #evergreen |
| 11:53 |
|
redavis joined #evergreen |
| 12:01 |
|
jihpringle joined #evergreen |
| 14:02 |
|
redavis_ joined #evergreen |
| 14:07 |
jeffdavis |
I've got a test server where generating Did You Mean suggestions is adding 23 seconds to the runtime of a keyword search, because the call to search.symspell_lookup has to process 62,000 potential suggestions. |
| 14:08 |
jeffdavis |
This is a 3.11 server. |
| 14:11 |
|
redavis joined #evergreen |
| 14:13 |
jeffdavis |
symspell dictionary was generated using the sideload script with the default values for internal flags (symspell.prefix_length = 6, symspell.max_edit_distance = 3) |
| 14:23 |
|
Dhruv_Fumtiwala joined #evergreen |
| 14:23 |
Dhruv_Fumtiwala |
copy_vis_attr_cache |
| 14:23 |
Dhruv_Fumtiwala |
Can you please help me as to what this table has information about. |
| 14:24 |
Dhruv_Fumtiwala |
It is under Asset Schema |
| 14:32 |
jeff |
it was formerly a trigger-materialized view that assisted in determining if items (asset.copy rows) were "visible" in searches, taking into account several different things that could make a copy "visible" or "not visible" in the public-facing catalog. It has been unused for a number of releases now. I don't recall offhand when it was replaced. |
| 14:33 |
jeff |
sorry, I'm wrong. |
| 14:33 |
jeff |
scratch that, reverse it. copy_vis_attr_cache replaced the table I just described.. |
| 14:33 |
jeff |
(I was describing the long-gone asset.opac_visible_copies) |
| 14:36 |
jeff |
there is a little more information available in this mailing list thread from 2019: http://list.evergreen-ils.org/pipermail/open-ils-dev/2019-June/010775.html |
| 14:36 |
jeff |
there may be better sources of that information, but I don't have them handy right now. |
| 14:42 |
Dhruv_Fumtiwala |
Apologies, but didn't quite get it. |
| 14:45 |
jeffdavis |
Basically, asset.copy_vis_attr_cache indicates which items attached to a bib record are visible for different types of catalog searches (e.g. at different search locations). |
| 14:46 |
jeffdavis |
When you do a search, Evergreen finds all the bib records that match your search terms, then uses copy visibility information from asset.copy_vis_attr_cache to exclude records that match your terms but don't have any copies at the libraries you are searching. |
| 14:47 |
jeffdavis |
I'm oversimplifying but that's the general idea. |
| 14:47 |
Dhruv_Fumtiwala |
Ohh, now it helped me make more sense. Thank You. |
| 14:50 |
jeffdavis |
Evergreen's internal technical documentation has a more detailed technical explanation here: https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=docs/TechRef/PureSQLSearch.adoc;hb=HEAD - but it's likely more detailed than you really want :) |
| 15:00 |
Dhruv_Fumtiwala |
Sure, Thanks |
| 15:16 |
jeffdavis |
realizing I mentioned our DYM-related search slowness issue last week - fwiw search.symspell_dictionary entries were generated using whatever version of sideload is in 3.11 and I explicitly excluded deleted bibs |
| 15:16 |
jeffdavis |
I've opened a Launchpad bug for the issue, bug 2038472 |
| 15:16 |
pinesol |
Launchpad bug 2038472 in Evergreen "Search suggestions can make searches very slow in 3.11" [Undecided,New] https://launchpad.net/bugs/2038472 |
| 15:43 |
jeff |
jeffdavis: possibly reading too much into your words, by "slow in 3.11" do you mean that there is a version of Evergreen prior to 3.11 where search suggestions did not result in very slow searches? |
| 15:45 |
|
kworstell-isl joined #evergreen |
| 15:45 |
Stompro |
In the angular catalog search, the opac hidden marc coded value maps that are not marked opac visible are showing. Is that a config option? |
| 15:45 |
jihpringle |
jeff: when I do a search on our 3.11 test server public catalogue it takes 52 seconds to give me any results, a search on PINES' catalogue takes seconds and they have DYM running in 3.10 |
| 15:50 |
jihpringle |
Strompo: it's a bug, we deleted the hidden ones off our server since we weren't using them anyways |
| 15:50 |
jihpringle |
Stompro ^^ |
| 15:51 |
jihpringle |
here's the original bug - https://bugs.launchpad.net/evergreen/+bug/1872867 |
| 15:51 |
pinesol |
Launchpad bug 1872867 in Evergreen "Angular Staff Catalog Format Drop Down List Not Using Search Labels or Observing OPAC Visible Value" [Undecided,Fix released] |
| 15:52 |
Stompro |
jihpringle++ thank you very much. |
| 15:52 |
jihpringle |
np :) |
| 15:53 |
jihpringle |
we never bothered to put in a new bug because deleting them fixed it for us and we currently have no need for Format filters that are only staff visible |
| 16:09 |
Stompro |
jihpringle, I filed bug 2038476 to start discussing just hiding them from staff also. |
| 16:09 |
pinesol |
Launchpad bug 2038476 in Evergreen "Angular Staff Catalog Format Drop Down - Observing OPAC Visible Value " [Undecided,New] https://launchpad.net/bugs/2038476 |
| 16:14 |
jihpringle |
great! |
| 17:11 |
|
mmorgan left #evergreen |
