1 2 3 Previous Next 31 Replies Latest reply: May 5, 2008 3:33 AM by Jonathan Lewis Go to original post RSS
      • 30. Re: Full Table Scan
        108476
        That's improved the tablescan by a factor of nearly 30 simply by changing the array fetch size, and doing nothing else
        Doh!

        Here I am, always advocating caching (SSD), and I neglected to consider that the table blocks were cached . . . . .
        There are far too many unknowns to uncover before suggesting that parallel query is the only way to speed things up.
        Whoa!

        Just because a problem has complex (but well-structured) rules, does not mean that it cannot be quantified! Assuming that the large table must be read from disk, we have:

        - DFMBRC
        - OPQ
        - Change stripe size
        - Change RAID
        - Use SSD ; )
        • 31. Re: Full Table Scan
          Jonathan Lewis
          There are far too many unknowns to uncover before
          suggesting that parallel query is the only way to
          speed things up.

          Whoa!

          Just because a problem has complex (but
          well-structured) rules, does not mean that it cannot
          be quantified! Assuming that the large table must be
          read from disk, we have:

          - DFMBRC
          - OPQ
          - Change stripe size
          - Change RAID
          - Use SSD ; )
          See, when pushed a little, you manage to think of five approaches that could improve performance, despite your original statement that parallel query was the only way to speed things up. There are more, of course, but well done.

          Now we just need more information from the OP about what he means by the tablescans being too slow, and we might be able to consider sensible options for improving things.

          Regards
          Jonathan Lewis
          http://jonathanlewis.wordpress.com
          http://www.jlcomp.demon.co.uk
          1 2 3 Previous Next