Forum Replies Created

Viewing 15 replies - 1 through 15 (of 40 total)
  • Thread Starter arypneta

    (@arypneta)

    Okay, thanks, that makes sense!

    Thread Starter arypneta

    (@arypneta)

    Thanks for the suggestions, Matthias! I think the click listener will probably do what we want, so that’s helpful to know the right class name to target.

    Thread Starter arypneta

    (@arypneta)

    That looks great, thank you so much!

    Thread Starter arypneta

    (@arypneta)

    I can’t easily send a screenshot, but as far as I can tell there already are indexes on those fields:

    Keyname: PRIMARY on column: term_taxonomy_id
    Keyname: term_id_taxonomy on columns: term_id and taxonomy
    Keyname: taxonomy on column taxonomy

    But the Trac ticket is a good idea. I might search there too if there’s already one open.

    That would be great if you have an idea to get around it for this plugin though. Thanks so much for your help!

    Thread Starter arypneta

    (@arypneta)

    We have about 180 users, but we use Co-Authors Plus which adds an additional author taxonomy (about 200 separate entries).

    However, we have like 12,700 tags, so I could see that being part of the issue even though it’s not querying those directly. From the EXPLAIN ANALYZE query, it does seem like the issue is something with the taxonomy (if I’m reading it correctly, which it’s entirely possible I’m not). This particular author only has 95 posts and wp_term_taxonomy is indexed on the taxonomy field (and it’s filtering by taxonomy=”author”), so I wouldn’t think that the tags would necessarily affect this query, but maybe they are. It looks like it’s finding a ton of rows and I’m really not sure why….

    -> Limit: 5 row(s) (no early end due to SQL_CALC_FOUND_ROWS)  (actual time=554..554 rows=5 loops=1)
    -> Sort: wp_posts.post_date DESC (actual time=554..554 rows=95 loops=1)
    -> Filter: (
    max(if((wp_term_taxonomy.taxonomy = 'author'),if((wp_term_taxonomy.term_id = 1443),2,1),0)) <> 1) (actual time=123..554 rows=95 loops=1)
    -> Stream results (cost=98692 rows=23086) (actual time=123..554 rows=95 loops=1)
    -> Group aggregate: max(if((wp_term_taxonomy.taxonomy = 'author'),if((wp_term_taxonomy.term_id = 1443),2,1),0)) (cost=98692 rows=23086) (actual time=123..553 rows=95 loops=1)
    -> Filter: ((wp_posts.post_author = 38) or ((wp_term_taxonomy.term_id = 1443) and (wp_term_taxonomy.taxonomy = 'author'))) (cost=83190 rows=155022) (actual time=123..553 rows=1051 loops=1)
    -> Nested loop left join (cost=83190 rows=155022) (actual time=0.0749..531 rows=184775 loops=1)
    -> Nested loop left join (cost=28932 rows=155022) (actual time=0.0639..128 rows=184775 loops=1)
    -> Filter: ((wp_posts.post_type = 'post') and ((wp_posts.post_status = 'publish') or (wp_posts.post_status = 'acf-disabled'))) (cost=10400 rows=11563) (actual time=0.0513..29.6 rows=14549 loops=1)
    -> Index scan on wp_posts using PRIMARY (cost=10400 rows=23124) (actual time=0.0496..21.7 rows=29511 loops=1)
    -> Covering index lookup on tr1 using PRIMARY (object_id=wp_posts.ID) (cost=0.262 rows=13.4) (actual time=0.0035..0.00596 rows=12.7 loops=14549)
    -> Single-row index lookup on wp_term_taxonomy using PRIMARY (term_taxonomy_id=tr1.term_taxonomy_id) (cost=0.25 rows=1) (actual time=0.00194..0.00196 rows=1 loops=184775)
    arypneta

    (@arypneta)

    The really weird thing is that we have sites with many more tags (including one with 1,000 more tags that is also using SSP) that don’t give us this error message. So, perhaps there’s some other plugin conflict.

    But anyway, the number of problems have been much reduced by the update, so this is probably fine for the time being.

    arypneta

    (@arypneta)

    Yeah, here you go. I think our hosting provider may be the one killing the query because it’s going on for too long:

    KILLED QUERY (16800 characters long generated in …./wp-content/plugins/seriously-simple-podcasting/php/includes/ssp-functions.php:1753): SELECT t.*, tt.* FROM wp_2_terms AS t INNER JOIN wp_2_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE t.term_id IN (1949,1386,1028,1027,725,8013,1504,605,1446,849,8016,2805,15331,7093,1808,3197,1763,1854,4748,7234,10475,91,979,220,1507,2410,6038,1138,12286,12288,4138,5444,5772,1010,2877,4384,13545,4032,1940,14074,192,16043,1905,2281,13311,1450,9958,305,19715,16512,3252,1293,543,1956,366,8197,4196,13717,19498,13952,13406,1939,840,1896,9126,982,3864,15578,7715,3160,767,10834,10835,7358,1861,2073,2860,10318,14643,13154,10508,2706,16329,1735,9115,3489,17565,1053,4139,4489,1146,1075,4191,4006,13987,1131,17309,17904,2809,11583,10137,19545,449,15626,11172,3624,1004,3627,848,4786,13212,2373,1835,304,4751,4669,1601,8805,1384,10542,4383,8325,907,2422,10128,19674,13167,3641,6269,2862,7830,15581,6602,19632,4928,3940,17908,12603,1717,12847,3280,19635,547,8570,735,1263,752,4618,2412,6975,708,13662,2436,327,1833,4791,4192,13123,8463,12370,981,3708,7081,8581,1525,1906,4752,2345,6571,16330,2026,4211,14439,8983,7458,1147,78,994,8960,1133,1196,1823,12174,15114,715,13293,13148,7005,2054,1193,6951,7357,5411,5380,6430,6199,6336,13244,14154,628,9233,15569,6899,1044,903,7741,7758,7675,10292,15613,12862,10894,2083,10783,10786,11171,3030,12998,13460,6394,367,13281,19393,4358,4403,13583,1923,1262,7266,19049,1011,13225,529,6345,412,2747,10935,6931,4895,1694,8801,6045,8631,5106,48,844,843,395,3695,2208,178,2016,1238,11789,4676,7864,9041 …..

    We had a lot of tags on this site, but when we started getting these errors, we cleaned out the list, so we’re down to about 4,500 tags, which doesn’t seem like a huge number to me given that we have more normal posts than that plus almost 350 posts of type podcast that also can have tags. But I don’t really know what a baseline normal number of tags is, so maybe that is way higher than most other sites using SSP.

    arypneta

    (@arypneta)

    @zahardoc Just to confirm, looks like it is about one error every couple days (which is a lot better than it was before). So, that should be fine for us, but if you were expecting no errors at all, we do still get them occasionally.

    arypneta

    (@arypneta)

    I upgraded to 3.9.0 on Friday and when I checked today, I only saw one error message about a “KILLED QUERY” from over the weekend. That’s significantly better than what we were experiencing before.

    When I previously reverted to 3.7.1, we stopped getting any of them, but one in three or four days is probably fine. I will keep checking it over the week and see if it increases when we have people in there actively working/posting articles.

    @vincec Good to know, thanks!

    I’m experiencing this issue as well, so I’m glad to see that a fix is on the way!

    Following… I’m having this issue too. I downgraded to 5.0.6 for now.

    Thread Starter arypneta

    (@arypneta)

    I saw that you had released version 9.2.1 after I submitted a support request, so I tried upgrading to that version and it seems to have solved the issues with 9.20. So, I think we’re good now, but thanks for following up!

    Thread Starter arypneta

    (@arypneta)

    Okay, good to know! For the generative AI filter, does that filter all of them out for the whole account? We would ideally be able to filter or not on each search. I know we have some of our users who prefer having non-generative AI for their photos, but a few who use them on occasion and might not want them filtered out. I’d have to check, but thanks for letting me know how to go about doing that!

    Thread Starter arypneta

    (@arypneta)

    Great, thanks! I had to change

    $image->id

    to

    $image->data->id

    to get the test snippet to work, but after that it was fine.

Viewing 15 replies - 1 through 15 (of 40 total)