• Envis10n@lemm.ee
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    This is only during an update to the community, correct? As in, changing some community setting?

    If that’s the case, it is ensuring that the languages selected for the community are a subset of the site languages and not some arbitrary value. Which is necessary for ensuring that funny business has not been done to the community settings via some raw call or request manipulation.

    If it’s only doing this on community edits, then the performance hit is worth it since it shouldn’t be done very frequently in the normal course of use.

    Try profiling the time it takes to complete the update request and see if it is actually as bad as you think.

    Another option would be to check the languages provided to see if they have been changed, and only do the subset check if they have. That’s really the only time it matters to make that check.

    • RoundSparrowOPM
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Try profiling the time it takes to complete the update request and see if it is actually as bad as you think.

      I didn’t figure 200,000 rows was running that slow, but I thought it was an easy entry point into analyzing code that allows parameter-less queries accidentally. site_aggregates has been an example in the code where lack of parameters was hitting 1500 rows when it was supposed to be hitting 1, same basic problem I suspect here.

      I know people are avoiding looking at the SQL in the project, simple things like this are not getting eyeballs:

          select c.creator_id from comment c
          inner join person u on c.creator_id = u.id
          inner join person pe on c.creator_id = pe.id