| Time |
Nick |
Message |
| 01:14 |
|
Guest76 joined #evergreen |
| 01:17 |
|
Guest76 joined #evergreen |
| 02:19 |
|
book`_ joined #evergreen |
| 07:49 |
|
rfrasur joined #evergreen |
| 08:13 |
|
Rogan joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 08:50 |
|
mantis1 joined #evergreen |
| 09:12 |
|
kworstell-isl joined #evergreen |
| 09:23 |
|
kmlussier joined #evergreen |
| 09:42 |
|
kworstell_isl joined #evergreen |
| 09:55 |
Dyrcona |
Too many git branches.... |
| 09:58 |
Dyrcona |
Also, testing 2-day (pre-due) courtesy notices with month-old data is kind of pointless. There were 6 without the "auto_renewal_remaining: 0" filter and none with it. |
| 10:09 |
Dyrcona |
Guess that's a 100% reduction. :) |
| 10:43 |
|
BrianK joined #evergreen |
| 11:44 |
|
rfrasur joined #evergreen |
| 11:49 |
|
jihpringle joined #evergreen |
| 11:51 |
Dyrcona |
Views built on views built on views.... |
| 11:51 |
Dyrcona |
No wonder the query is slow. |
| 11:52 |
jeff |
not always, but sometimes. |
| 11:53 |
Dyrcona |
Well, in this case, I think so. |
| 11:53 |
Dyrcona |
This is in reference to an email on the development list from this morning. |
| 11:56 |
jeff |
fun reminder: if "id" doesn't exist as a column in table bar, this will return all rows from table foo: SELECT id FROM foo WHERE id IN (SELECT id FROM bar); |
| 11:57 |
jeff |
because it's being interpreted as SELECT foo.id FROM foo WHERE foo.id IN (SELECT foo.id FROM bar) |
| 11:57 |
berick |
jeff: was about to ask to clarify :) |
| 12:00 |
Dyrcona |
I don't think that's apropos my comment, either. At least nothing I'm looking at uses subqueries. |
| 12:01 |
jeff |
no, unrelated to your comment. |
| 12:01 |
jeff |
sorry, i wasn't clearer there. :-) |
| 12:02 |
Dyrcona |
Heh. I should run tlittle's (or is it littlet in IRC?) on Pg 15 see if it's faster there. |
| 12:02 |
Dyrcona |
jeff: S'allright. |
| 12:02 |
Dyrcona |
Sometimes the answer is just upgrade. :) |
| 12:03 |
Dyrcona |
jeff: That's interesting what you point out. I would have expected an error that bar has no column 'id.' |
| 12:08 |
Dyrcona |
I suppose I could try and figure out what data from MARC is being used to build the wide_display_entry title and physical_description fields, or I could just take her word that she want the 300$n, and use 245$a for the title. :) |
| 12:09 |
Dyrcona |
My suspicion is this query will be faster if it drops the join on metabib.wide_display_entry and just grabs the data from MARC via XPath, since biblio.record_entry is already joined. |
| 12:09 |
Dyrcona |
The original is still running against my test database. |
| 12:10 |
jeff |
more detailed example that I just created: https://www.db-fiddle.com/f/9YseNbGnFVuqPkVJK85aew/0 |
| 12:16 |
jeff |
fun when "foo" is something like actor.usr or biblio.record_entry and "bar" is records_to_update or records_to_delete or the like. good reason to qualify your column references even when not forced to by ERROR: column reference "id" is ambiguous |
| 12:21 |
jeff |
I also had a recent fun one that I'll probably pick #postgresql about: I tend to favor WHERE NOT EXISTS (SELECT 1 FROM foo [...]) instead of LEFT JOIN foo ON [...] WHERE foo IS NULL for excluding things, especially if I'm not otherwise joining table foo in the query. I found at least one place where that was extremely detrimental fo my query's performance, ending up with a step where postgresql was |
| 12:21 |
jeff |
considering action.circulation rows * 100 where the 100 was apparently coming from the LIMIT in the query. |
| 12:22 |
jeff |
I think I probably picked up the NOT EXISTS (SELECT 1 ...) habit from https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_NOT_IN |
| 12:23 |
Dyrcona |
jeff: That where not exits might work with tlittle's query, and it could potentially speed things up. |
| 12:26 |
Dyrcona |
The original query is /still/ running. |
| 12:27 |
|
dguarrac joined #evergreen |
| 12:29 |
Dyrcona |
Negative logic is always funky. |
| 12:32 |
Dyrcona |
Grr. think I need the namespace mumbo jumbo for the xpath. XML-- |
| 12:35 |
Dyrcona |
It's Friday, and this like too much work for a Friday... :) |
| 12:41 |
Dyrcona |
Apparently, typing proper sentences is too much effort for a Friday. :) |
| 12:44 |
Dyrcona |
Long query is just long. I killed the original and started one that I thought should be faster, but it has been running for 15 minutes so far. |
| 12:47 |
Dyrcona |
I think I'll copy it to a vm that's closer to the database and less likely to lose its connection at random. |
| 12:53 |
Dyrcona |
Heh. Trying to find things that don't exist is hard. |
| 13:17 |
|
jihpringle6 joined #evergreen |
| 13:28 |
|
jihpringle joined #evergreen |
| 14:09 |
|
kmlussier joined #evergreen |
| 14:13 |
|
kworstell-isl joined #evergreen |
| 15:30 |
|
mantis1 left #evergreen |
| 16:02 |
Dyrcona |
So, the unmodified version of that query has been going for over 3 hours and 12 minutes on a test database. |
| 16:21 |
Dyrcona |
Think I'll stop and try my version. |
| 16:25 |
pinesol |
News from commits: Docs: adding image for Standing Penalties docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bbeeb8d42681f2d5a2419c6ed0683a34566dc832> |
| 16:27 |
|
jihpringle joined #evergreen |
| 16:51 |
|
jihpringle27 joined #evergreen |
| 19:33 |
|
tsadok joined #evergreen |
