| Time |
Nick |
Message |
| 06:17 |
|
gsams joined #evergreen |
| 07:21 |
|
graced joined #evergreen |
| 07:37 |
|
remingtron joined #evergreen |
| 07:56 |
|
jboyer-isl joined #evergreen |
| 07:57 |
|
rjackson_isl joined #evergreen |
| 07:57 |
|
sarabee joined #evergreen |
| 08:14 |
|
ericar joined #evergreen |
| 08:35 |
|
mrpeters joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:45 |
|
Shae joined #evergreen |
| 08:48 |
|
collum joined #evergreen |
| 08:56 |
|
dbwells joined #evergreen |
| 09:14 |
|
maryj joined #evergreen |
| 09:27 |
|
yboston joined #evergreen |
| 09:28 |
|
Dyrcona joined #evergreen |
| 09:29 |
Dyrcona |
Best explanation of pointers in C ever: http://en.wikipedia.org/wiki/Haddocks%27_Eyes |
| 09:30 |
Dyrcona |
Actually, not the poem itself, but the lead up to it. |
| 09:32 |
Dyrcona |
Start here with "You are sad," the Knight said in an anxious tone: http://en.wikisource.org/wiki/Page%3AThrough_the_Looking-Glass%2C_and_What_Alice_Found_There.djvu/194 |
| 09:32 |
Dyrcona |
And that's your programming lesson for today. :) |
| 09:35 |
Dyrcona |
Or, better: http://en.wikisource.org/wiki/Through_the_Looking-Glass,_and_What_Alice_Found_There/Chapter_VIII#174 |
| 09:36 |
|
pmurray_away joined #evergreen |
| 09:36 |
|
pmurray joined #evergreen |
| 09:37 |
mmorgan |
I thought stored somewhere in the db was the total circ count for copies ( including active, aged, and legacy). Maybe I dreamed this? |
| 09:38 |
csharp |
mmorgan: extend_reporter.full_circ_count is where I go for that |
| 09:39 |
mmorgan |
Yes! I didn't dream it after all :) |
| 09:39 |
mmorgan |
csharp++ |
| 09:39 |
mmorgan |
Thanks! |
| 09:41 |
jeff |
extend_reporter.full_circ_count outputs a row for each row in asset.copy, and gives a count that includes extend_reporter.legacy_circ_count, action.circulation, and action.aged_circulation |
| 09:43 |
Dyrcona |
It depends on legacy_circ_count having been filled at migration time. |
| 09:43 |
Dyrcona |
If not, legacy circs aren't included. |
| 09:43 |
jeff |
right. it isn't THAT magic. :-) |
| 09:44 |
Dyrcona |
:) |
| 09:44 |
Dyrcona |
It's all magic when you don't understand it. |
| 09:45 |
mmorgan |
Magic or not, it's pretty handy - as long as one knows where to look for it ;-) |
| 09:47 |
jonadab |
Any sufficiently advanced magic is indistinguishable from technology. |
| 09:52 |
Dyrcona |
jonadab++ |
| 09:52 |
Dyrcona |
I imagine if ancient people could see us, they would believe we are gods. |
| 09:56 |
|
RoganH joined #evergreen |
| 09:58 |
csharp |
@who is a god to the ancient people? |
| 09:58 |
pinesol_green |
dbwells is a god to the ancient people. |
| 10:24 |
Dyrcona |
@who is the OOM killer. |
| 10:24 |
pinesol_green |
kitteh_ is the OOM killer. |
| 10:24 |
* Dyrcona |
thinks his new hardware cannot come too soon. |
| 10:26 |
Dyrcona |
beam.smp is typically using around 1.8GB of virtual memory on our main server. |
| 10:26 |
Dyrcona |
I'm curious what others may see. |
| 10:31 |
dbwells |
csharp: sweet :) |
| 10:36 |
dbs |
Dyrcona: 1094m on our main (and only) server |
| 10:36 |
dbs |
Per top, anyway |
| 10:37 |
Dyrcona |
dbs: thanks, ours currently says: 1911m, but it varies. |
| 10:37 |
Dyrcona |
OOM killer decided to kill beam.smp yesterday afternoon. |
| 10:47 |
csharp |
@blame the OOM killa |
| 10:47 |
pinesol_green |
csharp: the OOM killa forgot to give the gerbils their chocolate-frosted sugar bombs |
| 11:03 |
|
dreuther joined #evergreen |
| 11:09 |
csharp |
hmm - I have a helpdesk ticket on long (> 25s) bib search queries - any clues on where I should be looking to decrease that? |
| 11:10 |
bshum |
Well, suggesting more refined search terms never hurts :) |
| 11:10 |
* csharp |
recalls conversations between eeevil and bshum at the hack-a-way about this, but doesn't know if they're relevant to him |
| 11:11 |
bshum |
csharp: What are they searching and how? |
| 11:11 |
bshum |
Certainly stuff can be slow depending on how they're searching. |
| 11:11 |
kmlussier |
csharp: Did they just start getting slow? |
| 11:11 |
bshum |
Like MARC expert search is still slow. |
| 11:11 |
csharp |
title:Night embrace search_format(book) site(URRLS-MA) depth(2) took 23s |
| 11:11 |
bshum |
Or copy location search |
| 11:12 |
csharp |
kmlussier: this is the first report of it, I'm only looking at Friday's logs right now and I haven't compared to earlier logs |
| 11:13 |
bshum |
csharp: All the stuff me and eeevil were talking about at the Hackaway were pushed to master and rel_2_7 |
| 11:13 |
csharp |
looking at the previous Friday's logs, there are similar search times |
| 11:13 |
bshum |
So, you probably should have everything. |
| 11:13 |
csharp |
bshum: great |
| 11:13 |
bshum |
And you did tune your PostgreSQL 9.3 with the different settings right? |
| 11:13 |
bshum |
Instead of what pgtune says to do |
| 11:14 |
Dyrcona |
Too much voodoo there. |
| 11:14 |
* Dyrcona |
is not a witchdoctor. |
| 11:15 |
csharp |
keyword: World War I search_format(book) depth(0) took 31s |
| 11:15 |
csharp |
bshum: yessir |
| 11:15 |
Dyrcona |
I'd expect a broad keyword search like that to take longer. |
| 11:16 |
csharp |
hmm - looks like search_format() may be a factor - still siftin |
| 11:16 |
csharp |
g |
| 11:17 |
csharp |
yep - excluding 'search_format' limits from the logs shows only 2-5 second queries |
| 11:19 |
kmlussier |
csharp: I think we've found that search_format does affect search times. |
| 11:19 |
kmlussier |
csharp: You might want to check with mmorgan when she's back. I know NOBLE has spent a lot of time recently trying to pin down search slowness. |
| 11:21 |
* csharp |
finally sees it - the example given to him was 'lusitania' which when searched scoped to a certain library only takes a second or two, but adding the books filter makes it sit and spin for many seconds |
| 11:23 |
csharp |
looks like item_type causes similar slowness |
| 11:24 |
Dyrcona |
Yep. I believe most of the filters go through a view made up of other views. |
| 11:24 |
Dyrcona |
Views built from views are generally not fast. |
| 11:24 |
bshum |
Not exactly anymore. |
| 11:24 |
Dyrcona |
Well, there were some improvements made, and I forget the details. |
| 11:24 |
bshum |
That was the work we were doing at the hackway, to not make them views of views. |
| 11:25 |
bshum |
Well, views of views of views? |
| 11:25 |
bshum |
:D |
| 11:25 |
Dyrcona |
:) |
| 11:26 |
Dyrcona |
I can say that we avoid those views in our SQL reports when searching by or retrieving that information. |
| 11:26 |
Dyrcona |
Using the views slows the queries down quite a lot. |
| 11:27 |
Dyrcona |
We generally join directly with ccvm and mravl. |
| 11:36 |
Dyrcona |
@blame mvf |
| 11:36 |
pinesol_green |
Dyrcona: mvf 's bugfix broke Dyrcona's feature! |
| 11:36 |
Dyrcona |
Hmm.. "Strike that. Reverse it." |
| 11:37 |
Dyrcona |
;) |
| 11:43 |
jeff |
huh. postgresql is tolerant of ambiguities in subqueries. |
| 11:47 |
jeff |
for example, https://gist.github.com/jeff/377e78b62f8aefcc3a7c |
| 11:49 |
jeff |
I was surprised that didn't trigger ``column reference "label" is ambiguous'' |
| 11:52 |
Dyrcona |
Interesting. |
| 11:54 |
Dyrcona |
Probably because there is no actual join in the subquery. |
| 11:54 |
jeff |
not sure if that's a bug (possibly even fixed after 9.2.mumble), or if I'm wrong to expect an error to be raised on that ambiguity. |
| 11:54 |
jboyer-isl |
Since it is a subselect it makes sense to me. I’d have been much more surprised if you said it treated it as acn.label rather than acnsub. |
| 11:56 |
jeff |
i guess "while acn.label can be explicitly referenced, the columns from acn are not otherwise made available to the subquery automatically" might explain it. |
| 11:56 |
jeff |
(if indeed that theory is correct) |
| 11:57 |
Dyrcona |
Maybe someone in #postgresql know? |
| 11:57 |
Dyrcona |
knows... |
| 11:57 |
jeff |
yeah, i might wrap it up in a form suitable for asking there. |
| 11:57 |
jeff |
after checking docs a little more. |
| 11:57 |
jeff |
tracking down something else first. |
| 12:12 |
eeevil |
jeff: pg nests "scopes" for subqueries. the nearest alias wins, given ambiguities |
| 12:14 |
jeff |
eeevil: thanks! |
| 12:14 |
jeff |
eeevil: any pointer / keywords offhand that i could use to find reference to that in the docs? |
| 12:22 |
eeevil |
jeff: the end of 2.1.2 (http://www.postgresql.org/docs/7.3/static/queries.html#QUERIES-WHERE) is pretty clear |
| 12:24 |
jeff |
not seeing a 2.1.2 there... |
| 12:24 |
eeevil |
heh... and for a /modern/ pg (same content) http://www.postgresql.org/docs/9.3/static/queries-table-expressions.html#QUERIES-WHERE |
| 12:25 |
eeevil |
the en d of 7.2.2 in that one |
| 12:25 |
jeff |
ah, there we go. thanks! |
| 12:25 |
jeff |
eeevil++ |
| 12:27 |
jeff |
i find myself pondering a function to rename a call number, or in the case of an existing call number with that label being already present, moving copies and optionally deleting the now-empty (when empty!) call number. |
| 12:28 |
jeff |
we do batch call number updates when moving/re-labeling, and while i can avoid trying to create a duplicate, the cleanup being manual is sometimes annoying. |
| 12:28 |
eeevil |
hrm... I thought there was a perl opensrf call to do exactly that... (obv less performant) |
| 12:29 |
jeff |
there might be -- it might require that the gaining/losing call numbers be known in advance. |
| 12:29 |
|
jihpringle joined #evergreen |
| 12:29 |
* jeff |
looks |
| 12:29 |
jeff |
because if i do the bulk of the update in sql then leave cleanup to a helper script that makes opensrf calls... |
| 12:31 |
Dyrcona |
Y'know, it occurs to me that I pretty much never refer to the "parent" query in a subquery. Habit, I guess. |
| 12:32 |
Dyrcona |
If I need to, I usually end up with a join or a with clause. |
| 12:32 |
jeff |
open-ils.cat.asset.volume.fleshed.batch.update has logic to auto-merge volumes if one with the same record+owner+label |
| 12:51 |
|
Dyrcona joined #evergreen |
| 12:52 |
|
yboston_ joined #evergreen |
| 12:54 |
|
Dyrcona joined #evergreen |
| 12:56 |
|
Dyrcona1 joined #evergreen |
| 12:58 |
Dyrcona |
Whee! Fun with wifi! |
| 13:08 |
* jeff |
vaguely wonders how old an evergreen database must be to have an action.billable_cirulations view |
| 13:14 |
jeff |
ah, was killed around 2009. |
| 13:30 |
|
mllewellyn joined #evergreen |
| 13:36 |
jeff |
that moment when someone hands you a printout and you think "wait, how was this generated?" |
| 13:37 |
jeff |
good reminder that there are corners of the UI that I never use, but others may use often. |
| 14:07 |
jonadab |
Heh. Our old ILS came with a bunch of canned reports. Every single time someone comes to me with a printout from one of them, asking what the numbers on it mean, I cringe. |
| 14:09 |
jeff |
"oh, you see, when sending a copy from library A to library B, the old ILS first checked it out to a pseudo-patron representing library B, then you applied the temporary barcode and sent it via courier..." |
| 14:10 |
jeff |
"once it arrived, library B checked it in, which checked it out to a pseudopatron account representing the hold shelf at library B, and in a day or two a postal notice would be printed at the main branch, and placed in the mail." |
| 14:10 |
jonadab |
That's actually remarkably similar to how we handle interlibrary loans. Except the other organization checks the book out to us... |
| 14:10 |
jeff |
"when the patron received the postal notice and came to library B, the item would be checked out to the patron's account" |
| 14:10 |
jeff |
"and yes, this item has now 'circulated' three more times than it had before the patron placed their request" |
| 14:10 |
jonadab |
... and we change the item-call-number associated with the barcode to the book title, then put it on the hold shelf... |
| 14:11 |
jonadab |
(The barcode on the 3x5 card, that is...) |
| 14:11 |
jeff |
"the item was 'checked out' to Library B, then to Library B's Hold Shelf, then to Patron Name Here. see? three circulations!" |
| 14:11 |
jonadab |
Heh. |
| 14:12 |
jonadab |
Well, I don't know about the Hold Shelf thing, but it's reasonable IMO for both library A and library B to count a circulation. |
| 14:12 |
jeff |
all a matter of intent and awareness. |
| 14:14 |
Dyrcona |
jonadab: The way we count things, both libraries do get credit for the 1 circulation in Evergreen. |
| 14:15 |
Dyrcona |
Library A gets a "reciprocal lending" credit for their item being circulated at Library B. |
| 14:15 |
Dyrcona |
Library B gets a simple circulation count for circulating an item. |
| 14:16 |
Dyrcona |
Only 1 goes into total circulations. |
| 14:16 |
csharp |
our libraries are pretty comfortable with the idea that circulations are counted only at the checkout library with the idea that it all comes out in the wash |
| 14:17 |
csharp |
however, they do keep stats on holds and transits to justify things too |
| 14:17 |
Dyrcona |
Our state wants to know how much libraries share materials, so we report that. |
| 14:17 |
csharp |
same here - it's PINES' raison d'etre |
| 14:41 |
jonadab |
Dyrcona: That makes sense. |
| 14:45 |
jeff |
and i've just spent several minutes editing the value in the following line wondering why i can't get it to work: |
| 14:45 |
jeff |
#log_min_duration_statement = 3 # -1 is disabled, 0 logs all statements |
| 14:45 |
jeff |
yes, that's commented out. :P |
| 14:46 |
bshum |
Heh |
| 14:47 |
jeff |
(and of course I meant a value much closer to 3000 than 3) |
| 14:50 |
Dyrcona |
Yep, that's the new standard in configuration files. Comment them out to use defaults. |
| 14:58 |
jonadab |
jeff: I once spent several *months* trying to figure out why about half my changes to a program didn't work. Somehow the entire source file had gotten duplicated, one copy after the other in the same file; the compiler ignored everything after the end of the first one... |
| 14:59 |
jonadab |
(This was on DOS, so needless to say I was not using version control.) |
| 15:01 |
|
ningalls joined #evergreen |
| 15:01 |
|
kbutler joined #evergreen |
| 15:04 |
|
dbs joined #evergreen |
| 15:29 |
|
mglass joined #evergreen |
| 15:33 |
|
sarabee joined #evergreen |
| 16:47 |
|
alynn26 joined #evergreen |
| 16:47 |
csharp |
gmcharlt++ # clip-the-cape-of-clark |
| 16:48 |
berick |
heh. kryptonite-lite |
| 16:58 |
|
Newziky left #evergreen |
| 17:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:22 |
|
mmorgan left #evergreen |
| 17:24 |
csharp |
@test |
| 17:24 |
pinesol_green |
csharp: Yeah, well, you know, that's just, like, your opinion, man. |
| 18:41 |
|
wlayton joined #evergreen |
| 22:27 |
|
dcook__ joined #evergreen |
