You've already had some good advice, but there's something much more simpler
that will also give you a significant boost: a covering index.
Simply put, the engine is smart enough to not bother with row lookups if
everything you asked for is already in the index it was using. You'll need to
On Thu, May 15, 2014 at 4:14 AM, Johan De Meersman vegiv...@tuxera.be wrote:
You've already had some good advice, but there's something much more simpler
that will also give you a significant boost: a covering index.
Simply put, the engine is smart enough to not bother with row lookups if
- Original Message -
From: Larry Martell larry.mart...@gmail.com
Subject: Re: Performance boost by splitting up large table?
This table is queried based on requests from the users. There are 10
different lookup columns they can specify, and they can provide any or
That makes
On Thu, May 15, 2014 at 11:01 AM, Johan De Meersman vegiv...@tuxera.be wrote:
- Original Message -
From: Larry Martell larry.mart...@gmail.com
Subject: Re: Performance boost by splitting up large table?
This table is queried based on requests from the users. There are 10
different
We have a table with 254 columns in it. 80% of the time, a very small
subset of these columns are queried. The other columns are rarely, if
ever, queried. (But they could be at any time, so we do need to
maintain them.). Would I expect to get a marked performance boost if I
split my table up into
Hi,
You could split the table into two and can avoid code changes by creating a
view which matches what code is looking for.
I think loading few fields vs 254 into memory will make a difference but if
your select statement only have specific fields you want and not the whole
row (and also given
Hi Larry,
On May 14, 2014, at 5:05 AM, Larry Martell larry.mart...@gmail.com wrote:
We have a table with 254 columns in it. 80% of the time, a very small
subset of these columns are queried. The other columns are rarely, if
ever, queried. (But they could be at any time, so we do need to
