Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Database & SysAdmin
  3. Database
  4. ORDER BY issue with Interbase XE SQL Server

ORDER BY issue with Interbase XE SQL Server

Scheduled Pinned Locked Moved Database
databasequestioncsssql-serversysadmin
4 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Offline
    L Offline
    Lost User
    wrote on last edited by
    #1

    Dear Experts I have a more or less complex query in my database which returns in average about 50 to 100 rows from a table let's say TBL_A containing about 1 million rows (this with left join to another table containg about 10 million records). The query itself returns the result in about 0.03 seconds which is pretty much nice I think. The amount of data per row is much less than 1KB. But as soon I add an "ORDER BY TBL_A.ID" the query needs 1.5 seconds; Where TBL_A.ID is the indexed primary key, integer. I assume the "query compiler" does try to use the index on TBL_A.ID to perform sorting and thats why the whole PLAN becomes inefficient. Question: Is there a way to tell the SQL Server not to use "TBL_A.ID index" for sorting and therfore force an "in Memory sorting"? Any hint is appreciated, also if it is MS SQL related, I think I can transform it by myself to Interbase. Note: A work around of course would be that I stay without ORDER BY in the query and let the client sort the result, but I don't like to do this. Thank you very much in advance for your hints.

    L 1 Reply Last reply
    0
    • L Lost User

      Dear Experts I have a more or less complex query in my database which returns in average about 50 to 100 rows from a table let's say TBL_A containing about 1 million rows (this with left join to another table containg about 10 million records). The query itself returns the result in about 0.03 seconds which is pretty much nice I think. The amount of data per row is much less than 1KB. But as soon I add an "ORDER BY TBL_A.ID" the query needs 1.5 seconds; Where TBL_A.ID is the indexed primary key, integer. I assume the "query compiler" does try to use the index on TBL_A.ID to perform sorting and thats why the whole PLAN becomes inefficient. Question: Is there a way to tell the SQL Server not to use "TBL_A.ID index" for sorting and therfore force an "in Memory sorting"? Any hint is appreciated, also if it is MS SQL related, I think I can transform it by myself to Interbase. Note: A work around of course would be that I stay without ORDER BY in the query and let the client sort the result, but I don't like to do this. Thank you very much in advance for your hints.

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #2

      0x01AA wrote:

      The query itself returns the result in about 0.03 seconds which is pretty much nice I think.

      If you insert into a new (temp) table and sort those 50-100 rows after the query has executed with a new command, how much time would that take?

      Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

      L 1 Reply Last reply
      0
      • L Lost User

        0x01AA wrote:

        The query itself returns the result in about 0.03 seconds which is pretty much nice I think.

        If you insert into a new (temp) table and sort those 50-100 rows after the query has executed with a new command, how much time would that take?

        Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #3

        Thank you very much for your reply. Using a temp table, then it takes nearly 0 seconds, but temp table with Interbase is very uncomfortable compared to MSSQL. And unfortunatelly there is nothing like like CTE in Interbase (at least what I know) :^) Thanks again. [Edit] :lol: Visited your Profile and read "I'm a Delphi-convert", so then I assume you know interbase. I'm on the way to become hopefully a "Borland c++" convert. :laugh:

        L 1 Reply Last reply
        0
        • L Lost User

          Thank you very much for your reply. Using a temp table, then it takes nearly 0 seconds, but temp table with Interbase is very uncomfortable compared to MSSQL. And unfortunatelly there is nothing like like CTE in Interbase (at least what I know) :^) Thanks again. [Edit] :lol: Visited your Profile and read "I'm a Delphi-convert", so then I assume you know interbase. I'm on the way to become hopefully a "Borland c++" convert. :laugh:

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          0x01AA wrote:

          Using a temp table, then it takes nearly 0 seconds, but temp table with Interbase is very uncomfortable compared to MSSQL.

          Wrap it in a transaction. Without committing, there is no temp table; should isolate the operation. Would work best as a stored procedure :) You're welcome ofc :)

          Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups