Steve,
> Past recommendations for a good RAID card (for SCSI) have been the LSI
> MegaRAID 2x. This unit comes with 128MB of RAM on-board. Has anyone
> found by increasing the on-board RAM, did Postgresql performed better?
My informal tests showed no difference between 64MB and 256MB.
--
--Josh
Past recommendations for a good RAID card (for SCSI) have been the LSI
MegaRAID 2x. This unit comes with 128MB of RAM on-board. Has anyone
found by increasing the on-board RAM, did Postgresql performed better?
Thanks.
Steve Poe
---(end of broadcast)---
Joel Fradkin wrote:
Is the battery backed cache good or bad for Postgres?
Battery-backed avoids corruption if you have an unexpected power loss.
It's considered mandatory with large-cache write-back controllers if you
can't afford to lose any data.
They are telling me I can only get a duel chann
Sebastian Hennebrueder wrote:
> I found a solution to improve my query. I do not know why but the
> statistics for all column has been 0.
> I changed this to 10 for index columns and to 20 for all foreign key
> columns.
> and to 100 for foreign key columns.
> I set the random page cost to 2
> and
I found a solution to improve my query. I do not know why but the
statistics for all column has been 0.
I changed this to 10 for index columns and to 20 for all foreign key
columns.
and to 100 for foreign key columns.
I set the random page cost to 2
and now the query runs as expected.
Many thank
>> Question, though: is HP still using their proprietary RAID
>card? And, if so,
>> have they fixed its performance problems?
>
>According to my folks here, we're using the CCISS controllers, so I
>guess they are. The systems are nevertheless performing very well --
>we did a load test that w
On Sat, May 07, 2005 at 02:00:34PM -0700, Josh Berkus wrote:
>
> Question, though: is HP still using their proprietary RAID card? And, if
> so,
> have they fixed its performance problems?
According to my folks here, we're using the CCISS controllers, so I
guess they are. The systems are neve
Joel wrote:
I have been following threads (in case you don't know I bought a 4 proc
Dell recently) and the Opteron seems the way to go.
I just called HP for a quote, but don't want to make any mistakes.
[snip]
At your level of play it's the DL585.
Have you checked out http://www.swt.com?
Merlin
We are up and somewhat happy.
I have been following threads (in case you don’t know
I bought a 4 proc Dell recently) and the Opteron seems the way to go.
I just called HP for a quote, but don’t want to make
any mistakes.
Is the battery backed cache good or bad for Postgres?
The
Ð ÐÑÐ, 11/05/2005 Ð 22:59 +0200, Guillaume Smet ÐÐÑÐÑ:
> Anyway, I tried to work on the statistics as you told me and here are
> the results:
> ccm_perf=# ALTER TABLE acs_objects ALTER COLUMN object_id SET STATISTICS 30;
> ALTER TABLE
> ccm_perf=# ANALYZE acs_objects;
> ANALYZE
>
> ccm_perf=# \i
Greg Stark wrote:
Sebastian Hennebrueder <[EMAIL PROTECTED]> writes:
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
...
"Nested Loop (cost=1349.13..1435.29 rows=1 width=2541) (actual
time=1640.000..3687.000 rows=62 loops=1)"
" Join Filter: ("inner".fid = "outer".faufgaben_id)"
" -> Ind
Quoting Tom Lane <[EMAIL PROTECTED]>:
> "Mindaugas Riauba" <[EMAIL PROTECTED]> writes:
> > ... So contents of database changes very fast. Problem is that
> when
> > pg_autovacuum does vacuum those changes slows down too much.
>
> The "vacuum cost" parameters can be adjusted to make vacuums fired
"Mindaugas Riauba" <[EMAIL PROTECTED]> writes:
> Hm. Yes. Number of locks varies quite alot (10-600). Now what to
> investigate
> further? We do not use explicit locks in our functions. We use quite simple
> update/delete where key=something;
> Some sample (select * from pg_locks order by pid)
Chris,
> It is widely believed that a somewhat larger default than 10 would be
> a "good thing," as it seems to be fairly common for 10 to be too small
> to allow statistics to be stable. But nobody has done any formal
> evaluation as to whether it would make sense to jump from 10 to:
>
> - 15?
On Fri, May 13, 2005 at 05:45:45PM +0300, Mindaugas Riauba wrote:
> But there's no checkpoint warnings in serverlog. And btw we are running
> with fsync=off (yes I know the consequences).
Just a note here; since you have battery-backed hardware cache, you
probably won't notice that much of a slo
> >>The "vacuum cost" parameters can be adjusted to make vacuums fired
> >>by pg_autovacuum less of a burden. I haven't got any specific numbers
> >>to suggest, but perhaps someone else does.
> >
> > It looks like that not only vacuum causes our problems. vacuum_cost
> > seems to lower vacuum i
Mindaugas Riauba wrote:
The "vacuum cost" parameters can be adjusted to make vacuums fired
by pg_autovacuum less of a burden. I haven't got any specific numbers
to suggest, but perhaps someone else does.
It looks like that not only vacuum causes our problems. vacuum_cost
seems to lower vacuum im
> > It looks like that not only vacuum causes our problems. vacuum_cost
> > seems to lower vacuum impact but we are still noticing slow queries
"storm".
> > We are logging queries that takes >2000ms to process.
> > And there is quiet periods and then suddenly 30+ slow queries appears
in
> > lo
"Mindaugas Riauba" <[EMAIL PROTECTED]> writes:
> It looks like that not only vacuum causes our problems. vacuum_cost
> seems to lower vacuum impact but we are still noticing slow queries "storm".
> We are logging queries that takes >2000ms to process.
> And there is quiet periods and then sudde
> > ... So contents of database changes very fast. Problem is that when
> > pg_autovacuum does vacuum those changes slows down too much.
>
> The "vacuum cost" parameters can be adjusted to make vacuums fired
> by pg_autovacuum less of a burden. I haven't got any specific numbers
> to suggest, but
"Mindaugas Riauba" <[EMAIL PROTECTED]> writes:
> ... So contents of database changes very fast. Problem is that when
> pg_autovacuum does vacuum those changes slows down too much.
The "vacuum cost" parameters can be adjusted to make vacuums fired
by pg_autovacuum less of a burden. I haven't got a
On Fri, May 13, 2005 at 03:52:38PM +0300, Mindaugas Riauba wrote:
> Tables are not big (2-15 rows each) but have very high
> turnover rate - 100+ updates/inserts/deletes/selects per second.
> So contents of database changes very fast. Problem is that when
> pg_autovacuum does vacuum those
Hello,
We have problems with one postgresql database with high
data change rate. Actually we are already under pressure
to change postgresql to Oracle.
I cannot post schema and queries to list but can do this
privately.
Tables are not big (2-15 rows each) but have very high
turn
23 matches
Mail list logo
