On Mon, Jan 03, 2005 at 01:44:27PM -0800, Adam Palmblad wrote:
> I've got a table using a data type that I have created as the type for
> its primary key. I (hope) I have the type set up properly - it seems
> okay, and does not have any problem creating a b-tree index for the
> type. The problem
...and on Mon, Jan 03, 2005 at 03:44:44PM -0500, Mitch Pirtle used the keyboard:
>
> You are right, I now remember that setup was originally called "RAID
> 10 plus 1", and I believe is was an incorrect statement from an
> overzealous salesman ;-)
>
Just an afterthought - that could well be the unf
William Yu wrote:
Dave Cramer wrote:
William Yu wrote:
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings
on my 8GB Opteron server and 10K seems to be the best setting.
Be careful here, he is not u
[EMAIL PROTECTED] wrote:
I realize you may be stuck with 7.3.x but you should be aware that 7.4
is considerably faster, and 8.0 appears to be even faster yet.
There are a little bit incompatibility between 7.3 -8 , so rather difficult
to
change.
I would seriously consider upgrading, if at
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Add a small cost factor to ensure we
>> prefer materializing the smaller input. This changes several
>> regression test plans, but with any luck we will now have more
>> stability across platforms.
> No. The planner is not a facto
Besides the tables pg_stat_xxx, are there any stronger tools for
PostgreSQL as the counterpart of Oracle's Statspack? Is it possible at
all to trace and log the cpu and io cost for each committed
transaction?
Thanks a lot! -Stan
__
Do You Yahoo!?
T
Well, it's not quite that simple
the rule of thumb is 6-10% of available memory before postgres loads is
allocated to shared_buffers.
then effective cache is set to the SUM of shared_buffers + kernel buffers
Then you have to look at individual slow queries to determine why they
are slow, fortuna
Hi ,
I am experiencing a very bad performance on my production database
lately , all my queries are slowing down. Our application is a webbased
system with lot of selects and updates. I am running "vacuumdb" daily on
all the databases, are the below postgres configuration parameters are
set
I've got a table using a data type that I have
created as the type for its primary key. I (hope) I have the type set up
properly - it seems okay, and does not have any problem creating a b-tree index
for the type. The problem I am having is that the index seems to never be
chosen for use.
Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > I took advantage of the holidays to update a production server (dual
> > Opteron on win2k) from an 11/16 build (about beta5 or so) to the
latest
> > release candidate. No configuration changes were made, just a
binary
> > swap and
You are right, I now remember that setup was originally called "RAID
10 plus 1", and I believe is was an incorrect statement from an
overzealous salesman ;-)
Thanks for the clarification!
- Mitch
On Mon, 03 Jan 2005 15:19:04 -0500, Madison Kelly <[EMAIL PROTECTED]> wrote:
> Madison Kelly wrote:
Madison Kelly <[EMAIL PROTECTED]> writes:
> Without it, specially in a failure state, the performance can collapse as
> the CPU performs all that extra math.
It's really not the math that makes raid 5 hurt. It's that in order to
calculate the checksum block the raid controller needs to read in t
Madison Kelly wrote:
Nope, Raid 10 (one zero) is a mirror is stripes, no parity. with r10
Woops, that should be "mirror of stripes".
By the way, what you are thinking of is possible, it would be 51 (five
one; a raid 5 built on mirrors) or 15 (a mirror of raid 5 arrays).
Always be careful, 10 a
Dave Cramer wrote:
William Yu wrote:
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings on
my 8GB Opteron server and 10K seems to be the best setting.
Be careful here, he is not using opterons which
Mitch Pirtle wrote:
On Mon, 13 Dec 2004 09:23:13 -0800, Joshua D. Drake
<[EMAIL PROTECTED]> wrote:
RAID 10 will typically always outperform RAID 5 with the same HD config.
Isn't RAID10 just RAID5 mirrored? How does that speed up performance?
Or am I missing something?
-- Mitch
Hi Mitch,
Nope,
On Mon, 13 Dec 2004 09:23:13 -0800, Joshua D. Drake
<[EMAIL PROTECTED]> wrote:
>
> RAID 10 will typically always outperform RAID 5 with the same HD config.
Isn't RAID10 just RAID5 mirrored? How does that speed up performance?
Or am I missing something?
-- Mitch
---(end
On Monday 03 January 2005 10:40, [EMAIL PROTECTED] wrote:
> > I realize you may be stuck with 7.3.x but you should be aware that 7.4
> > is considerably faster, and 8.0 appears to be even faster yet.
>
> There are a little bit incompatibility between 7.3 -8 , so rather difficult
> to change.
>
Sur
Hi,
are there any plans for rewriting queries to preexisting materialized
views? I mean, rewrite a query (within the optimizer) to use a
materialized view instead of the originating table?
Regards,
Yann
---(end of broadcast)---
TIP 6: Have you sea
> I realize you may be stuck with 7.3.x but you should be aware that 7.4
> is considerably faster, and 8.0 appears to be even faster yet.
There are a little bit incompatibility between 7.3 -8 , so rather difficult to
change.
> I would seriously consider upgrading, if at all possible.
>
> A few mo
amrit wrote:
> I try to adjust my server for a couple of weeks with some sucess but
it
> still
> slow when the server has stress in the moring from many connection . I
> used
> postgresql 7.3.2-1 with RH 9 on a mechine of 2 Xeon 3.0 Ghz and ram of
4
> Gb.
> Since 1 1/2 yr. when I started to use the
Amrit,
I realize you may be stuck with 7.3.x but you should be aware that 7.4
is considerably faster, and 8.0 appears to be even faster yet.
I would seriously consider upgrading, if at all possible.
A few more hints.
Random page cost is quite conservative if you have reasonably fast
disks.
William Yu wrote:
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings on
my 8GB Opteron server and 10K seems to be the best setting.
Be careful here, he is not using opterons which can access physical
Decrease the sort mem too much [8196] make the performance much slower
so I use
sort_mem = 16384
and leave effective cache to the same value , the result is quite better
but I
should wait for tomorrow morning [official hour] to see the end result.
You could also profile your queries to see w
Amrit --
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Mon 1/3/2005 12:18 AM
>To:Mark Kirkwood
>Cc:PGsql-performance
>Subject: Re: [PERFORM] Low Performance for big hospital server ..
>> shared_buffers = 12000 will use 12000*8192 bytes (i.e a
William Yu wrote:
[EMAIL PROTECTED] wrote:
Yes , vacuumdb daily.
Do you vacuum table by table or the entire DB? I find over time, the
system tables can get very bloated and cause a lot of slowdowns just due
to schema queries/updates. You might want to try a VACUUM FULL ANALYZE
just on the system
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings on my
8GB Opteron server and 10K seems to be the best setting.
also effective cache is the sum of kernel buffers + shared_buffers so it
should be big
> shared_buffers = 12000 will use 12000*8192 bytes (i.e about 96Mb). It is
> shared, so no matter how many connections you have it will only use 96M.
Now I use the figure of 27853
> >
> >Will the increasing in effective cache size to arround 20 make a little
> bit
> >improvement ? Do you thin
27 matches
Mail list logo
