Recently we upgraded the RAM in our server. After the install a LIKE query that used
to take 5 seconds now takes 5 minutes. We have tried the usual suspects, VACUUM,
ANALYZE and Re-indexing.
Any thoughts on what might have happened?
-Garrett Bladow
---(end of broadcast
Hi-
I have a table- called "event" with a field event_date_time that is indexed.
There are 1,700,000 rows in the table and 92,000 distinct values of
event_date_time with anywhere from 1 to 400 rows sharing the same value. (I
did a count grouped by event_date_time & scanned it to get this info.)
W
Vivek Khera wrote:
> And the winner is... checkpoint_segments.
>
> Restore of a significanly big database (~19.8GB restored) shows nearly
> no time difference depending on sort_mem when checkpoint_segments is
> large. There are quite a number of tables and indexes. The restore
> was done from a
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
BM> restore, even if there is no value to it being large during normal
BM> server operation. Should that be decumented?
Yes, right alongside the recommendation to bump sort_mem, even though
in my tests sort_mem made no significant differen
> "RT" == Robert Treat <[EMAIL PROTECTED]> writes:
RT> hmm... i wonder what would happen if you pushed your sort_mem higher...
RT> on some of our development boxes and upgrade scripts, i push the
RT> sort_mem to 102400 and sometimes even higher depending on the box. this
RT> really speeds up m
