7

Me : So cool ! My new graphQL APIs are working so good !
Also me : ‘order by <text field> take 50 skip 10000’
Me : Hmmmm.. 2.3 SEDCONDS ?! WTF. Let’s add an index !
SQL : Sorry bro, can’t add index on nvrachar(max).
Me: OK. Here you go, you are nvrachar(128) now. Add my index !
SQL : Ok
GraphQl :<same query > Here : 90 milliseconds
Me : ‘order by <text field> desc take 50 skip 10000’
GraphQL : Sorry bro : 3 seconds. (Yes, slower than without any index)
Me : Do I fu7cking need to manually add ASC and DESC indexes ? WTF IS GOING ON !
I should’ve learnt a bit more about databases. ☹. And now I don’t have time to refactor a prod database as “needed” .
/me needs to buy DB audit. Company is still a bit small to have a DBA full time.

Comments
  • 1
    Update :

    Ok, i'm lost.

    Ordering by ID !!! (Which is int and a primary key and have an index. Where clause is on indexed column also) :
    Ascending : 50 ms / page
    Descending : 600ms/page

    wtf ?
  • 1
    Which database?
  • 1
    Are you joining tables?
  • 4
    You forget one thing: it all boils down to how the data is stored on disk.

    Most databases sort by primary index by default as the underlying structure is something "treeish" / "kv-sorted" (where k is primary key and value is a tuple consisting of the associated row data).

    Hence, when you sort ASC, stuff can be read as is from index / disk.

    But if you sort DESC, you need to do a full evaluation of expression, sort the resulting set (or if DB is clever, reverse it) and then can return it.

    In databases, knowing storage is most of the time essential to understand index related behaviour.
  • 0
    @IntrusionCM Thanks ! That explains most of my current problems !
  • 0
    @sbiewald
    In this case : Azure SQL
Add Comment