×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 19-Jun-2014 11:29 -0500, Graap, Kenneth wrote:
We recently installed 8 SSD on our system.
These units are in the same iASP as several older HDD’s.
We can’t allocate all of our “HOT” files to the SSD’s because of
space limitations.
If I had to choose between locating Physical File data or the
Logical File indexes built over this data on SSD, which type of file
would provide the best performance boost being located on SSD, the
PF’s or the LF’s
I would choose according to what I perceived to provide [or better,
as verified by testing provides] the greatest benefits to the
applications; I would not choose based solely on a file type [logical vs
physical] designation. Clearly, a logical file access path that is
utilized with an /index-only/ query implementation would effect more
beneficial performance when located on SSD than instead, having the
physical data on the SSD; i.e. the data from the PF would not be
referenced, because the data comes from the access path itself.
Even an index\access-path that merely allows a query to limit the
physical data to a /small/ amount of rows might be more worthwhile being
accessed from SSD than the actual data, if that AccPth is used very
often. That can be important even if the PF data access is slower due
to not coming from SSD. If the amount of physical data storage
requirements is going to limit the high-use and efficient access methods
[per Keyed Access Path access methods] from taking advantage of the SSD
storage, then the net effect of PF on SSD could be much worse than if
some of those AccPth were on SSD instead. The benefit of the PF data on
SSD is lowest when only a /small/ portion of its rows are being accessed
by an efficient sparse access path processing, and similarly if data for
many of the columns are rarely accessed, because in either case the SSD
storage taken for low-use data directly limits storage for those access
paths that can quickly find those [more popular] rows.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.