| Time |
Nick |
Message |
| 01:52 |
|
geoffsams joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:39 |
|
graced joined #evergreen |
| 07:46 |
|
krvmga joined #evergreen |
| 07:50 |
|
mrpeters joined #evergreen |
| 07:57 |
|
rjackson_isl joined #evergreen |
| 08:07 |
|
collum joined #evergreen |
| 08:22 |
|
akilsdonk joined #evergreen |
| 08:31 |
|
DPearl1 left #evergreen |
| 08:32 |
|
Newziky joined #evergreen |
| 08:33 |
kmlussier |
gmcharlt: Following up on your trademark email, the minutes from http://wiki.evergreen-ils.org/doku.php?id=governance:minutes:2012-10-17 lead me to believe it's not a draft policy and doesn't need finalization from the EOB. Does that sound right to you? |
| 08:33 |
|
Callender joined #evergreen |
| 08:34 |
gmcharlt |
kmlussier: I'll need to go through it; I think there is a pending (minor) issue about the the logo itself, but I think you are probably correct that the overall policy was approved |
| 08:34 |
kmlussier |
ok, thanks! |
| 08:39 |
|
Shae joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 09:10 |
|
Dyrcona joined #evergreen |
| 09:10 |
|
akilsdonk joined #evergreen |
| 09:18 |
|
Newziky left #evergreen |
| 09:23 |
|
akilsdonk joined #evergreen |
| 09:26 |
|
maryj joined #evergreen |
| 09:27 |
|
yboston joined #evergreen |
| 09:46 |
csharp |
gmcharlt: also, if you want the files from the GPLS server, I'm sure I can get those to you - just need to check with a couple of folks on this end that all is ok |
| 09:46 |
gmcharlt |
csharp: thanks! |
| 10:40 |
|
collum joined #evergreen |
| 10:47 |
jboyer-isl |
eeevil: I thought I'd try to test the inverse of your fix for bug 1438136 (common searches, uncommon attributes, I think), but I can't use the queries in that ticket to find common or uncommon values in pg 9.1. Do you know off hand of a good way to get those on more uh, mature, versions of pg? |
| 10:47 |
pinesol_green |
Launchpad bug 1438136 in Evergreen "OPAC searching significantly slowed by adding format filters" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1438136 |
| 10:51 |
|
mllewellyn joined #evergreen |
| 10:54 |
eeevil |
jboyer-isl: let me look. in the mean time, were you able to test the branch, or does it not work for you on 9.1? |
| 10:55 |
rjackson_isl |
eeevil: jboyer-isl is afk currently - just thought I would let you know as he isn't ignoring you! |
| 10:55 |
eeevil |
jboyer-isl: ah ... well, I can tell it wont work. the array stats arrive in 9.2 |
| 10:55 |
eeevil |
rjackson_isl: thanks! :) |
| 10:57 |
|
ningalls joined #evergreen |
| 11:06 |
jboyer-isl |
I haven't tested the branch itself (only the core query test in the ticket) because the only non-production database machines I have available are miserably slow regardless of what's searched how. :( |
| 11:09 |
eeevil |
jboyer-isl: ha! understood |
| 11:21 |
jeff |
something i haven't spent much time thinking about yet, but thought I'd throw out for feedback: we have the materialized view asset.opac_visible_copies, which aiui is mostly (exclusively?) for performance reasons -- it saves us from having to join a lot of things and examine a lot of columns at search time. |
| 11:22 |
eeevil |
jeff: yes |
| 11:22 |
csharp |
I put the branch on a test server and am seeing much better search returns, but for some reason, running the core query from one of the search attempts took just as long as before - I'm assuming I was doing something dumb (I'll add that I was exhausted when I looked last night ;-)) |
| 11:23 |
csharp |
next.gapines.org vs. gapines.org (if someone is interested in front end results) |
| 11:23 |
csharp |
next has the patch, gapines.org doesn't |
| 11:23 |
jeff |
with that as (very light) inspiration, would a materialized view representing (something like) record, circ_lib, shelving location be of much help in making locations() filtering faster, or in enabling crazy things like faceting on copy locations? |
| 11:24 |
jeff |
also, does the idea get crazier if you expand/replace the idea with copy location groups? |
| 11:25 |
csharp |
specific searches: http://gapines.org/eg/opac/results?query=lusitania&qtype=keyword&fi%3Asearch_format=book&locg=117&sort= vs http://next.gapines.org/eg/opac/results?query=lusitania&qtype=keyword&fi%3Asearch_format=book&locg=117 |
| 11:25 |
eeevil |
csharp: but, now they're cached ;) |
| 11:25 |
csharp |
doh! |
| 11:26 |
csharp |
I guess changing the query= in the URL would demonstrate ;-) |
| 11:28 |
eeevil |
csharp: it would, yes |
| 11:32 |
|
ningalls joined #evergreen |
| 11:33 |
|
RBecker joined #evergreen |
| 11:33 |
eeevil |
jeff: for cases where the copy locations only have a few copies, it's possible, but for locations with more copies than you'd get from the tsearch part, it would be a slowdown ... we could "facet" by location today, really, if someone added the appropriate widget. that's effectively what happens on the advanced search page |
| 11:34 |
eeevil |
by "it's possible" I mean "it's possible that it could be faster" |
| 11:36 |
eeevil |
jeff: IOW, you want the core query to focus on conditions that will return the smallest possible set given the whole search request, and I doubt that, other than things like "display" locations, copy location would be /that/ ... if that makes sense |
| 11:38 |
jeff |
i think i follow, yes. |
| 11:39 |
jeff |
and thinking about it a bit more, the only time "that's slow / incomplete / etc" is the classic problematic "empty search with JUST a locations() filter" |
| 11:39 |
Stompro |
Hello, for those staying in Portland on Saturday night of the conference, which hotel are you staying at? |
| 11:40 |
jeff |
Stompro: i am staying at PDX to wait for my midnight flight out :-) |
| 11:40 |
Stompro |
I'm looking to be lazy and not have to look at tripadvisor reviews. |
| 11:40 |
Dyrcona |
Stompro: The airport Marriott for me. |
| 11:41 |
jeff |
er, "the only time" is perhaps inaccurate, but I think I gave the general idea. |
| 11:41 |
Stompro |
Jeff: fun, my flight out is at 5:30am, so that means I need to get there at ~4:30 or earlier... maybe I should just stay up that night :) If I was 25 I might be able to handle that:) |
| 11:42 |
jeff |
"filtering on a bunch of locations" isn't nearly as problematic (perhaps not problematic at all) compared to "trying to 'browse' all copies in a location by doing an empty search with a locations() filter" |
| 11:42 |
Dyrcona |
Courtyard Portland Airport |
| 11:43 |
Stompro |
Dyrcona, thanks. |
| 11:44 |
Dyrcona |
I can paste the phone number if you like. |
| 11:44 |
Dyrcona |
Or pm it. |
| 11:44 |
Stompro |
Dyrcona, no need but thanks for the offer. |
| 11:45 |
jonadab |
jeff: Isn't there a way to limit the number of rows returned to a thousand, or something? |
| 11:45 |
Dyrcona |
My flight out is scheduled for 6:45 am Sunday, so not as bad as yours, but still early enough that leaving from Hood River makes no sense. |
| 11:46 |
Stompro |
Dyrcona, they have no rooms available according to their website, so I'll have to keep looking. |
| 11:46 |
Dyrcona |
Oops. |
| 11:52 |
jeff |
jonadab: the problem as i understand it (and i might not) with "show me everything in this shelving location" is that it essentially looks for everything at the library/libraries in scope, then filters those results -- and the first "find everything" is limited to a max of X items (configurable, but not without performance impact) |
| 11:52 |
jeff |
jonadab: so since you're not really trying to search but mostly trying to browse, it probably makes sense to have a better approach. it isn't (that I've found) THAT common a use case, but we occasionally do run into it. |
| 11:53 |
jeff |
"show me all the puppets", for example. |
| 11:53 |
jonadab |
Ah. |
| 11:53 |
jeff |
now arguably that could also be done with something like local subjects... |
| 11:53 |
|
sandbergja joined #evergreen |
| 11:54 |
|
ningalls joined #evergreen |
| 11:55 |
eeevil |
jeff: that's a case where it might be useful to optimize -- when we see there are locations, but no search terms. like a smarter version of what we do for bucket searches. we'd surely want a mat view for that, which has a cost as well (albeit not hugenormous) |
| 11:56 |
jeff |
eeevil: and using a container-like approach might make more sense than trying to use the actual "browse" or "shelf browse by shelving location, not call number". |
| 11:57 |
jeff |
eeevil++ thanks for the feedback |
| 11:57 |
eeevil |
for small record sets, yep, I agree. |
| 11:57 |
eeevil |
np |
| 11:58 |
eeevil |
fwiw, containers seem better for "new books" and "display" and such anyway, since they're transient "states", and you'll probably want to batch edit the items at some point, which containers facilitate |
| 12:01 |
jeff |
copy location is "better" for other reasons like the OPAC displaying that the item is in a display location, or checkin giving an alert that the copy needs to go to an unusual location, etc. |
| 12:01 |
eeevil |
jeff: right, that makes sense |
| 12:02 |
eeevil |
so, container for search, location for inventory management |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:07 |
jeff |
and part of me would want auto-population of the container based on the copy locations, treating location as the authoritative part. |
| 12:08 |
jeff |
(to avoid the requirement for duplicate staff action and/or conflicts between location/container) |
| 12:09 |
jeff |
and then a few thoughts later i remember that i have the day off as soon as i finish this task that i'm not working on. :-) |
| 12:09 |
eeevil |
a new container type ("location"?) and some triggers, and a bool on the location to control if it exists... interesting thought |
| 12:10 |
jeff |
yeah... middle ground between nothing and building some special purpose mat view. |
| 12:11 |
jeff |
are "large" containers a problem, or is that just "large containers with many many (MANY!) duplicate items"? |
| 12:15 |
jeff |
this ticket needs an infographic/dashboard of its own. "Number of support technicians participating", "Instances of 'thank you for your patience', 'Please accept our apologies for the delay in response'"... |
| 12:16 |
eeevil |
jeff: heh... LARGE ones would not be a good thing, but there's no difference between "has dupes" and unique today. |
| 12:17 |
jeff |
"number of attempts to reissue certificate: 6, i think?", "number of certificates that have been issued which violate CA/Browser Forum Basic Requirements for validity period: see previous number" |
| 12:17 |
eeevil |
we could make LARGE ones less painful by pushing the LIMIT into the container select |
| 12:18 |
eeevil |
the CTE, I mean |
| 12:41 |
|
graced joined #evergreen |
| 12:42 |
eeevil |
@later tell jboyer-isl I've pushed another commit to the working branch for bug 1438136 that will protect your ANCIENT version of postgres ;) |
| 12:42 |
pinesol_green |
eeevil: The operation succeeded. |
| 12:43 |
kmlussier |
eeevil: I'm curious. Will the branch help the search query on that ancient version? Or is the commit you just added a "do no harm" thing? |
| 12:44 |
* kmlussier |
thinks there is still a MassLNC site on 9.1. |
| 12:47 |
Dyrcona |
Umm, us... |
| 12:53 |
kmlussier |
Dyrcona: Oh, you're not the site I was thinking of. :) |
| 12:53 |
kmlussier |
Correction, two MassLNC sites. |
| 12:53 |
kmlussier |
I give up. I can't keep track of you all anymore. :) |
| 12:55 |
|
Newziky joined #evergreen |
| 12:55 |
|
Newziky left #evergreen |
| 12:55 |
Dyrcona |
heh |
| 12:56 |
Dyrcona |
S'ok. Neither can I. |
| 13:00 |
eeevil |
kmlussier / Dyrcona: it will help, yes, if you're hitting the problem, but you might not be. based on the plans I saw the other day, you aren't |
| 13:01 |
Dyrcona |
eeevil: Cool. We'll be on 9.3 or 9.4 before too long. |
| 13:01 |
Dyrcona |
I'll build a new branch on Monday if anyone cares. |
| 13:02 |
Dyrcona |
This time I'll make sure my database reload actually happens. :) |
| 13:09 |
Dyrcona |
tsbere just reminded me that Monday is Patriots' Day, so make that Tuesday. |
| 14:10 |
kmlussier |
Dyrcona: Just back from a conference call. Did you say you're building a new branch on your dev server? |
| 14:11 |
Dyrcona |
kmlussier: Yes, on Tuesday. It won't differ much from what I loaded yesterday. |
| 14:22 |
|
Newziky joined #evergreen |
| 14:36 |
jeff |
nothing worse than a non-tuned postgres instance that you only need once a year or so. |
| 14:37 |
jeff |
...and you're in a hurry |
| 14:38 |
|
TaraC joined #evergreen |
| 14:38 |
|
TaraC_ joined #evergreen |
| 14:38 |
tsbere |
jeff: At least it is functional? |
| 14:39 |
|
dbs joined #evergreen |
| 14:46 |
|
ningalls joined #evergreen |
| 15:18 |
|
TaraC joined #evergreen |
| 15:22 |
jeff |
ERROR: invalid input syntax for type money: "John Smith" |
| 15:22 |
jeff |
tsbere: functional database, or functional data? :-) |
| 15:23 |
eeevil |
jeff: you and I have differing definitions of "nothing" methinks |
| 15:23 |
tsbere |
jeff: Apparently I need to revise my statement. ;) |
| 15:24 |
jeff |
eeevil: yeah, "nothing worse than" was perhaps a bit hyperbolic. :-) |
| 15:25 |
Dyrcona |
I'll see your John Smith and raise you 2 Bob Hopes. |
| 15:29 |
jeff |
some good news, though: my certificate supplier has provided me with a workaround while the CA tries to get better at math. |
| 15:42 |
eeevil |
welp, it's a good think we didn't go down the super-dense seamicro server route a couple years ago... http://seamicro.com |
| 15:43 |
jeff |
eeevil: yikes |
| 15:43 |
|
Newziky left #evergreen |
| 16:03 |
* dbwells |
sheds a tear for his AMD stock |
| 16:06 |
Dyrcona |
Stompro++ # For testing with Jessie. |
| 16:58 |
|
gsams joined #evergreen |
| 16:58 |
|
StomproJ joined #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:40 |
|
Newziky joined #evergreen |
| 19:28 |
|
akilsdonk joined #evergreen |
| 21:40 |
|
kmlussier joined #evergreen |
| 21:40 |
|
mceraso joined #evergreen |
| 21:40 |
|
bshum joined #evergreen |
| 21:42 |
|
Callender joined #evergreen |
