On Thu, Aug 11, 2005 at 07:13:27PM -0400, Jeffrey Tenny wrote:
The system for testing was 512MB
That's definately *not* a "large ram" system. If you're reading a subset
of data that totals 70MB I'm going to guess that your data set is larger
than or at least a large fraction of 512MB.
additional memory. However there was no swap activity on that system,
so I doubt memory was the limiting factor.
The system won't swap if your data set is larger than your memory, it
just won't cache the data.
Well, that's what you'd expect. But a first time 70MB fetch on a
freshly rebooted system took just as long as all secondary times. (Took
over a minute to fetch, which is too long for my needs, at least on
secondary attempts).
If the query involves a table scan and the data set is larger than your
available memory, you'll need a full scan every time. If you do a table
scan and the table fits in RAM, subsequent runs should be faster. If you
have an index and only need to look at a subset of the table, subsequent
runs should be faster. Without knowing more about your queries it's not
clear what your situation is.
Mike Stone
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
