Kevin Grittner ha scritto:
Silvio Brandani wrote:
we have a performance issue on deleting data from a table.
the delete is on the index key so should be very fast but the table
have 13 contraints of type foreign keys and the slowness seems due
to all the works done with the constraint.
Tr
Silvio Brandani wrote:
> we have a performance issue on deleting data from a table.
>
> the delete is on the index key so should be very fast but the table
> have 13 contraints of type foreign keys and the slowness seems due
> to all the works done with the constraint.
> Trying to drop the const
Hi alls,
we have a performance issue on deleting data from a table.
the delete is on the index key so should be very fast but the table
have 13 contraints of type foreign keys and the slowness seems due to
all the works done with the constraint.
Trying to drop the constraint and execute the d
Jessica Richard wrote:
I am tuning a database created by someone else.
I noticed that some column lengths were defined longer than needed.
For example, an Id column is holding a stand length of 20 characters but
was defined as varchar(255).
On some other columns, for example, a Description c
Jessica Richard wrote:
I am tuning a database created by someone else.
I noticed that some column lengths were defined longer than needed.
For example, an Id column is holding a stand length of 20 characters
but was defined as varchar(255).
On some other columns, for example, a Description col
I am tuning a database created by someone else.
I noticed that some column lengths were defined longer than needed.
For example, an Id column is holding a stand length of 20 characters but was
defined as varchar(255).
On some other columns, for example, a Description column is supposed to hold
Hi Rainer,
On Tue, Feb 05, 2008 at 10:24:11AM +1300, Rainer Spittel wrote:
> You are right, this query is not the right approach for performance
> testing. I thought that this will give an indication about the
> performance of a select statement on that table.
Only do benchmarking with real-wo
"Rainer Spittel" <[EMAIL PROTECTED]> writes:
> One of those slow queries are running on col02 which has a btree
> index. But I use the 'in' expression to get a set of matching rows:
> select * from table where col02 in ('...',[...],'...')
> This query gets sometimes really slow, I guess it d
Hi Tom,
You are right, this query is not the right approach for performance
testing. I thought that this will give an indication about the
performance of a select statement on that table.
One of those slow queries are running on col02 which has a btree
index. But I use the 'in' expression to
Hi Rainer,
On Tue, Feb 05, 2008 at 09:07:26AM +1300, Rainer Spittel wrote:
> When performing a 'select col01_id from table limit 1 offset 10;',
As Tom already stated, the result of this query is a bit random since
there is no ordering at all. What are you actually querying for?
Try tuning q
"Rainer Spittel" <[EMAIL PROTECTED]> writes:
> When performing a 'select col01_id from table limit 1 offset 10;',
> the query takes up to 20sec. Monitoring the dstats on the server, I see
> that the box is reading approx. 1GB from the disks.
No surprise. That query says "read 11 rows, the
Hi guys,
I am not really new to Postgres, but to be honest I am not an expert
on the internal configuration of Postgres. I run a couple of
PostgreSQL/PostGIS databases on several servers, but two of them are not
performing very well. Those two databases are just read-only databases
and they get
12
> [EMAIL PROTECTED]
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Carol Walter
>> Sent: Wednesday, January 02, 2008 10:35 AM
>> To: pgsql-admin@postgresql.org
>> Subject: [ADMIN] Performance tuni
Hi Carol,
On Wed, Jan 02, 2008 at 10:34:47AM -0500, Carol Walter wrote:
> This has probably been discussed a number of times, but I really need
> your help. I am upgrading from 8.1 to 8.2. Right now I have the
> restore of the database to the new version running. It has been
> running si
On Jan 2, 2008 9:34 AM, Carol Walter <[EMAIL PROTECTED]> wrote:
> Greetings and Salutations...
>
> This has probably been discussed a number of times, but I really need
> your help. I am upgrading from 8.1 to 8.2. Right now I have the
> restore of the database to the new version running. It has
t: Wednesday, January 02, 2008 10:35 AM
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Performance tuning...
>
> Greetings and Salutations...
>
> This has probably been discussed a number of times, but I
> really need your help. I am upgrading from 8.1 to 8.2.
>
Greetings and Salutations...
This has probably been discussed a number of times, but I really need
your help. I am upgrading from 8.1 to 8.2. Right now I have the
restore of the database to the new version running. It has been
running since December 21, at 4:30 PM. I'm in a University
MAIL PROTECTED]
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Performance benchmarking
I think you have already got your answer...
NO you do not need any kind of license to use PostgreSQL as it an Open
Source. You can do anything you want to do.
- Vishal
>From: lai yoke hman <[EMAIL
lai yoke hman wrote:
>
> Hello,
> I am an undergraduate of a university in Malaysia, if I want to do
> performance benchmark on PostgreSQL 8, do I need to get a license agreement
> or some sort of thing?
> Thanks.
Your license, provided without charge, is here:
http://www.postgresql.org/about/l
I think you have already got your answer...
NO you do not need any kind of license to use PostgreSQL as it an Open
Source. You can do anything you want to do.
- Vishal
From: lai yoke hman <[EMAIL PROTECTED]>
To:
Subject: [ADMIN] Performance benchmarking
Date: Fri, 6 Jul 2007 01
Hello,
I am an undergraduate of a university in Malaysia, if I want to do performance
benchmark on PostgreSQL 8, do I need to get a license agreement or some sort of
thing?
Thanks.
_
Did you know you can now customize your mailbox w
No, you can do with it whatever you want, except blame/sue the copyrightholder
for any problems you might have with it (software is AS IS).
On Thursday 05 July 2007, lai yoke hman wrote:
> Hello,
> I am an undergraduate of a university in Malaysia, if I want to do
> performance benchmark on Post
lai yoke hman wrote:
>
> Hello,
> I am an undergraduate of a university in Malaysia, if I want to do
> performance benchmark on PostgreSQL 8, do I need to get a license agreement
> or some sort of thing?
> Thanks.
No. PostgreSQL is open source.
Joshua D. Drake
>
>
>
Hello,
I am an undergraduate of a university in Malaysia, if I want to do performance
benchmark on PostgreSQL 8, do I need to get a license agreement or some sort of
thing?
Thanks.
_
Check out some new online services that are so
On May 23, 2007, at 10:11 PM, Jair Elton Batista wrote:
How to monitor PgSQL performance, like JConsole for Java Virtual
Machine? Usage of memory, CPU, etc.
Use the OS level tools. There's also a chapter in the documentation
dedicated to monitoring.
--
Jim Nasby
How to monitor PgSQL performance, like JConsole for Java Virtual Machine?
Usage of memory, CPU, etc.
Thank you,
Jair.
How to monitor PgSQL performance, like JConsole for Java Virtual Machine?
Usage of memory, CPU, etc.
Thank you,
Jair.
Rickard =?iso-8859-1?b?U2r2c3Ry9m0=?= <[EMAIL PROTECTED]> writes:
> I have a view that is really slow and I ca easily work around the slowness by
> bypassing the view and query the real table directly.
Let's see the exact definition of the view and EXPLAIN ANALYZE results
for doing it both ways.
Hi!
I've probably missed somthing but here is my problem.
I have a view that is really slow and I ca easily work around the slowness by
bypassing the view and query the real table directly.
Example:
>From view, the slow one:
SELECT * from my_view WHER
> To: Benjamin Krajmalnik
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Performance question
>
> Please cc the list so others can learn and help.
>
> Yes, if ODBC is tearing the connection down after every call,
> performance *WILL* suck. Setup some kind of persisten
mp or timestamp without
> timezone?
>
>
> > -Original Message-
> > From: Jim Nasby [mailto:[EMAIL PROTECTED]
> > Sent: Monday, December 04, 2006 5:53 PM
> > To: Benjamin Krajmalnik
> > Cc: pgsql-admin@postgresql.org
> > Subject: Re: [ADMIN] Perfo
Are you sure you're doing an apples-apples comparison? Is the load on
both machines the same, or does production have extra stuff running?
Have you tried your original test again in the same setup without
ODBC to eliminate that possibility? (or redone your original test
with ODBC).
As for
I am battling a performance issue and was wondering if someone could
help. PostgreSQL 8.1.5, FreeBSD.
I have a very intense stored procedure which performs real time
aggregation of data.
I captured the stored procedure calls from a production system and
pumped them through psql, logging duration
06 4:38 PM
> To: Benjamin Krajmalnik> Cc: pgsql-admin@postgresql.org> Subject: RE: [ADMIN] Performance tuning question>>> > isweb01# vmstat 10
> > procs memory pagedisks faults> > cpu> > r b w avmfre flt re pi po fr s
> I just finished running some benchmarks on an underpowered server
> compared to the one I am running in production.
> My initial tests were run on an ampty database, pg_xlog on the same
> spindle.
> Stored procedure execution speed was ~15 ms.
>
> I then restored the production database so I wo
a separate spindle, are there any other things
you can think of which may improve the performance?
> -Original Message-
> From: Chris Mair [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 07, 2006 4:38 PM
> To: Benjamin Krajmalnik
> Cc: pgsql-admin@postgresql.org
> S
> isweb01# vmstat 10
> procs memory pagedisks faults
> cpu
> r b w avmfre flt re pi po fr sr ad4 ad6 in sy cs us
> sy id
> 1 0 0 648368 47052 10322 0 0 0 7505 136 0 0 839 6241 2114
> 18 10 71
> 1 0 0 651392 42464 9823 0 0
n Krajmalnik
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Performance tuning question
>
> On Mon, 2006-08-07 at 02:18 -0600, Benjamin Krajmalnik wrote:
>
> > I just migrated from PG 8.1.4 Windows to 8.1.4 FreeBSD/i386.
>
> Good move :)
>
> > All of
On Mon, 2006-08-07 at 02:18 -0600, Benjamin Krajmalnik wrote:
> I just migrated from PG 8.1.4 Windows to 8.1.4 FreeBSD/i386.
Good move :)
> All of the data insertion to the database is done via a stored procedure
> call.
> I did some benchmarking, and on an empty database the execution time of
>
I just migrated from PG 8.1.4 Windows to 8.1.4 FreeBSD/i386.
All of the data insertion to the database is done via a stored procedure
call.
I did some benchmarking, and on an empty database the execution time of
the stored procedure was about 5 ms on average.
This was done running via EMS SQL Mana
an IngenCc:
pgsql-admin@postgresql.orgSubject: Re: [ADMIN] Performance Slowly
Decreasing As Database GrowsCheck the stats at the end of
your vacuum to ensure your max_fsm_pages (free space map) is large enough. Also
check work_mem and maintenance_work_mem are not running at defaults that may be
too
Check the stats at the end of your vacuum to ensure your max_fsm_pages (free space map) is large enough. Also check work_mem and maintenance_work_mem are not running at defaults that may be too small. If you have many updates, increase the number of wal_buffers and checkpoint_segments.
On 7/11/06,
I am using Postgresql 8.1.4 on Windows 2003; platform is Dell Precision 330,
1.8 Ghz
CPU, 1 gByte of RAM. This database is subject to 'vacuum full analyze' once
/ day.
I am watching a recently created database grow; as it grows, I am finding
that some of the performance statistics appear to be fal
* david drummard ([EMAIL PROTECTED]) wrote:
> thanks very much for the response. Are there any special commands to analyze
> the index before using the table. If i rename the table, will the indexes
> still stay with the table ( i hope so).
You want to run 'analyze ' after you've created the inde
hi stephen,
thanks very much for the response. Are there any special commands to
analyze the index before using the table. If i rename the table, will
the indexes still stay with the table ( i hope so).
best regards
vijay erantiOn 2/10/06, Stephen Frost <[EMAIL PROTECTED]> wrote:
* david drummar
* david drummard ([EMAIL PROTECTED]) wrote:
> My question is what is the best way to do step (1) so that after the copy is
> done, the table is fully indexed and properly balanced and optimized for
> query.
> Should i create indexes before or after import ? I need to do this in
> shortest period o
I have an unique requirement. I have a feed of 2.5 - 3 million rows of
data which arrives every 1/2 an hour. Each row has 2 small string
values (about 50 chars each) and 10 int values. I need
searcheability and running arbitrary queries on any of these values.
This means i have to create an index
[EMAIL PROTECTED] (Aldor) writes:
> I'm curious how other people do it:
>
> What is faster?
>
> 1. CREATE TABLE
> 2. restore data
> 3. CREATE INDEX
>
> or
>
> 1. CREATE TABLE
> 2. CREATE INDEX
> 3. restore data
Creating the index AFTER loading the data is definitely faster. But
by all means do yo
On Mon, Sep 26, 2005 at 01:30:53AM +0100, Aldor wrote:
> What is faster?
>
> 1. CREATE TABLE
> 2. restore data
> 3. CREATE INDEX
>
> or
>
> 1. CREATE TABLE
> 2. CREATE INDEX
> 3. restore data
See "Populating a Database" in the "Performance Tips" chapter of
the documentation:
http://www.postgre
Hi,
I'm curious how other people do it:
What is faster?
1. CREATE TABLE
2. restore data
3. CREATE INDEX
or
1. CREATE TABLE
2. CREATE INDEX
3. restore data
Thanks,
Aldor
---(end of broadcast)---
TIP 6: explain analyze is your friend
the problem is solved...
once i reverted back to 9.1...things seems to be much better.
i also revamped a lot of my code to optimize it for speed.
will post the results after i complete a sizable chunk of my data.
the in also seems to working much better now...
thanx
---(end
Ruud,
thanx for your reply.
I am narrowing down on the problem...found that Suse 9.2 has a lot of
memory related problems.
reverted back to 9.1 and rebuilding the app..will post an update.
you suggestion will not work for me though...i need to check existing
records and create new records..which
looks like reducing shared_buffers and turning off archiving might be
helping...i will post a followup in a few days...
kind of disappointed that no one bothered to reply yet though.
---(end of broadcast)---
TIP 6: Have you searched our list archive
i am having poor performance with postgres 8.0.0
the config of my machine is:
single xeon 3.4 Ghz, 1GB of memory, two IDE drives mounted using LVM and
JFS file system on Suse 9.2 professional.
What I am trying to do is simple...atleast in ORACLE or DB2 that I am
trying to stay away from.
I have
in
Subject: Re: [ADMIN] Performance Question
The long and short of it is that you should never need to restart
either the main server or postgres in order to achieve better
performance. If the issue is that you are not vacuuming frequently
enough, then you might consider pg_autovacuum, which is
more info will be helpful, please let me know!
Many thanks
-Original Message-
From: Thomas F. O'Connell [mailto:[EMAIL PROTECTED]
Sent: 19 March 2005 08:09 PM
To: Werner vd Merwe
Cc: PgSQL Admin
Subject: Re: [ADMIN] Performance Question
The long and short of it is that you should
No, I mean JDBC version, not JDK version.
go to jdbc.postgresql.org and download newest version of JDBC to
have a try.
regards laser
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining colum
what' your JDBC version?
if it's pretty old, then upgrade to newest one is a bet.
Don't know if it could solve the problem, but old
version of JDBC did have some problem in transaction
handling, we've experienced such problem not so long
before.
regards laser
---(end of broa
records in, with 15 fields,
around
15000 records per day added.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
F.O'Connell
Sent: 14 March 2005 06:37 PM
To: Werner vd Merwe
Cc: PgSQL Admin
Subject: Re: [ADMIN] Performance Question
Well, the
Dnia Åroda, 16 marca 2005 15:05, Scott Marlowe napisaÅ:
> On Wed, 2005-03-16 at 07:46, Marcin Giedz wrote:
> > Dnia wtorek, 15 marca 2005 18:00, Scott Marlowe napisaÅ:
> >
> > OK now I know I mys query lasts so long:
> >
> > SELECT DISTINCT t1.Id, t1.IdTypNazwa, t1.IdFirma, t1.Nazwa,
> > t1.NazwaAs
On Wed, 2005-03-16 at 07:46, Marcin Giedz wrote:
> Dnia wtorek, 15 marca 2005 18:00, Scott Marlowe napisaÅ:
>
> OK now I know I mys query lasts so long:
>
> SELECT DISTINCT t1.Id, t1.IdTypNazwa, t1.IdFirma, t1.Nazwa, t1.NazwaAscii,
> t1.MskNazwa, t3.Id, t3.numer, t3.MskNumer, t4.Id, t4.numer, t4.
Dnia wtorek, 15 marca 2005 18:00, Scott Marlowe napisaÅ:
OK now I know I mys query lasts so long:
SELECT DISTINCT t1.Id, t1.IdTypNazwa, t1.IdFirma, t1.Nazwa, t1.NazwaAscii,
t1.MskNazwa, t3.Id, t3.numer, t3.MskNumer, t4.Id, t4.numer, t4.MskNumer,
t5.Id, t5.numer, t5.MskNumer, t6.Id, t6.numer, t6.M
-Original Message-
From: weiping [mailto:[EMAIL PROTECTED]
Sent: 15 March 2005 05:55 PM
To: Werner vd Merwe
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Performance Question
what' your JDBC version?
if it's pretty old, then upgrade to newest one is a bet.
Don't k
[mailto:[EMAIL PROTECTED] On Behalf Of Brad Nicholson
Sent: 15 March 2005 05:33 PM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Performance Question
Werner vd Merwe wrote:
>Output of VACUUM ANALYSE VERBOSE pg_listener:
>
>Query OK, 0 rows affected (0.06 sec)
>INFO: vacuuming &qu
On Tue, 2005-03-15 at 10:17, Marcin Giedz wrote:
> Dnia wtorek, 15 marca 2005 17:08, Scott Marlowe napisaÅ:
> > On Tue, 2005-03-15 at 02:59, Marcin Giedz wrote:
> > > Dnia poniedziaÅek, 14 marca 2005 19:32, Scott Marlowe napisaÅ:
> > > > On Mon, 2005-03-14 at 12:03, Marcin Giedz wrote:
> > > > > He
Dnia wtorek, 15 marca 2005 17:08, Scott Marlowe napisaÅ:
> On Tue, 2005-03-15 at 02:59, Marcin Giedz wrote:
> > Dnia poniedziaÅek, 14 marca 2005 19:32, Scott Marlowe napisaÅ:
> > > On Mon, 2005-03-14 at 12:03, Marcin Giedz wrote:
> > > > Hello...
> > > >
> > > >
> > > > Our company is going to chan
On Tue, 2005-03-15 at 02:59, Marcin Giedz wrote:
> Dnia poniedziaÅek, 14 marca 2005 19:32, Scott Marlowe napisaÅ:
> > On Mon, 2005-03-14 at 12:03, Marcin Giedz wrote:
> > > Hello...
> > >
> > >
> > > Our company is going to change SQL engine from MySQL to PSQL. Of course
> > > some performance prob
d Nicholson
Sent: 14 March 2005 07:10 PM
To: PgSQL Admin
Subject: Re: [ADMIN] Performance Question
I'm wondering if long running transacations might be the cause (you'll
likely want to do this while perfomance is suffering).
Have a look at pg_stat_activity and see if there are any lon
Dnia poniedziałek, 14 marca 2005 19:32, Scott Marlowe napisał:
> On Mon, 2005-03-14 at 12:03, Marcin Giedz wrote:
> > Hello...
> >
> >
> > Our company is going to change SQL engine from MySQL to PSQL. Of course
> > some performance problems occured. Our server is Dual Xeon 3.0GHz + 8GB
> > RAM + RA
F.O'Connell
Sent: 14 March 2005 06:37 PM
To: Werner vd Merwe
Cc: PgSQL Admin
Subject: Re: [ADMIN] Performance Question
Well, there's always the dbsize module in contrib to check actual size
on disk. I was thinking more in terms of approximate numbers of tables
and rows in those tables.
-tfo
-
On Mon, 2005-03-14 at 12:03, Marcin Giedz wrote:
> Hello...
>
>
> Our company is going to change SQL engine from MySQL to PSQL. Of course some
> performance problems occured. Our server is Dual Xeon 3.0GHz + 8GB RAM +
> RAID1(software - two 146GB SCSI 15k) for sql data + RAID1(software - two
>
Hello...
Our company is going to change SQL engine from MySQL to PSQL. Of course some
performance problems occured. Our server is Dual Xeon 3.0GHz + 8GB RAM +
RAID1(software - two 146GB SCSI 15k) for sql data + RAID1(software - two
146GB SCSI 15k) for pg_xlog. Postgres.conf parameters are as f
ly slow. Not broken after the vacuum, it is a gradual
decline in performance.
Hope that makes more sense.
Many thanks
-Original Message-
From: Thomas F. O'Connell [mailto:[EMAIL PROTECTED]
Sent: 14 March 2005 05:59 PM
To: Werner vd Merwe
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN
Original Message-
From: Thomas F. O'Connell [mailto:[EMAIL PROTECTED]
Sent: 14 March 2005 05:59 PM
To: Werner vd Merwe
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Performance Question
I think you need to provide more information to get any help with your
setup.
For one thing, why are you
From: Thomas F. O'Connell [mailto:[EMAIL PROTECTED]
Sent: 14 March 2005 05:59 PM
To: Werner vd Merwe
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Performance Question
I think you need to provide more information to get any help with your
setup.
For one thing, why are you "restart
I think you need to provide more information to get any help with your
setup.
For one thing, why are you "restarting"? Are you restarting the server?
Postgres? In general, there should be no need to restart either.
Next, what do you mean by "broken bad" after a full vacuum?
-tfo
--
Thomas F.
Hi guys,
I have been browsing around and reading up on PostgreSQL
performance to try and tweak our system at the office, as its performance is
not that great.
Many people say that PG is a great DB, and I know that our
problems are purely a setup issue.
After a complete server re
OK, I found the thread you mentioned and installed the Qos Service on my
win2K netwerk, but it gave no effect. So it must be something else in
this case.
Pascal Van Puymbroeck
ZENON productions bvba
---(end of broadcast)---
TIP 7: don't forget to
Pascal Van Puymbroeck <[EMAIL PROTECTED]> writes:
> I would like to solve a strange behaviour I encountered using Postgresql
> 8.0.1 on windows. Connecting to the database is OK, but when running a
> query to the database, its terribly slow. The fact is that I need the
> database to be running
Hi folks,
I would like to solve a strange behaviour I encountered using Postgresql
8.0.1 on windows. Connecting to the database is OK, but when running a
query to the database, its terribly slow. The fact is that I need the
database to be running on the same machine, my application is. So I
2004 3:59
PM
Subject: [ADMIN] Performance 7.3.4
We are trying to upgrade postgres 7.2 to postgres
7.3.4. We are having problems with some reports that have an excellent
performance in 7.2 and now, in 7.3.4 the performance is too bad. Did someone
have this problem? What should we do?
Title: Performance 7.3.4
We are trying to upgrade postgres 7.2 to postgres 7.3.4. We are having problems with some reports that have an excellent performance in 7.2 and now, in 7.3.4 the performance is too bad. Did someone have this problem? What should we do?
Thanks to all
I will try the various options out and look to see if we can upgrade
and let you know the result.
It will take a few days as I am not officially here but on
holiday??
Frank
>>> Frank Finner <[EMAIL PROTECTED]> 31/05/04 15:03:02 >>>
Hi,
I had a similiar problem with 7.3.5 some
In article <[EMAIL PROTECTED]>,
"Frank Smith" <[EMAIL PROTECTED]> writes:
> Hi
> ID:7
> I am running PostgreSQL 7.2.2 on Red Hat 9 and I am suffering a growing
> performance problem. The problem shows through a slowing of queries and
> an increase in the system CPU usage. Queries that took le
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Frank Smith") would write:
> Hi
>
> ID:7
>
> I am running PostgreSQL 7.2.2 on Red Hat 9 and I am suffering a
> growing performance problem. The problem shows through a slowing of
> queries and an increase in the system CPU usage. Queri
Hi
ID:7
I am running PostgreSQL 7.2.2 on Red Hat 9 and I am suffering a growing
performance problem. The problem shows through a slowing of queries and
an increase in the system CPU usage. Queries that took less than 6
seconds clime to take more than 5 minutes and as the system is driven by
A
Hello,
Currently I can get no more than 40k records/second to be copied
in to postgres. This is also the case when running multiple
cocurrent copy in commands from different connections. It
seems linear in that 1 process will copy in at 40k/s and 2
will copy in at about 20k/s, etc.
I need to kno
I'm running several 7.3.4 database servers and would like to turn on all of
the statistic collectors to help with tuning. However, I don't have an idea
of what sort of performance impact doing this would have.
Does anyone have any rough numbers or documentation links that discuss the
performance
On Thu, 6 Nov 2003, William Yu wrote:
> scott.marlowe wrote:
> > Note that if you're on an IDE drive and you haven't disabled the write
> > cache, you may as well turn off fsync as well, as it's just getting in the
> > way and doing nothing, i.e. the IDE drives are already lying about fsync
> >
Quoth [EMAIL PROTECTED] (Stephen Frost):
> * Christopher Browne ([EMAIL PROTECTED]) wrote:
>> On one of our test servers, I set "fsync=false", and a test load's
>> load time dropped from about 90 minutes to 3 minutes. (It was
>> REALLY update heavy, with huge numbers of tiny transactions.)
>>
>>
* Christopher Browne ([EMAIL PROTECTED]) wrote:
> On one of our test servers, I set "fsync=false", and a test load's
> load time dropped from about 90 minutes to 3 minutes. (It was REALLY
> update heavy, with huge numbers of tiny transactions.)
>
> Which is, yes, quite spectacularly faster. But
[EMAIL PROTECTED] (Jeff) writes:
> On 06 Nov 2003 15:21:03 +0100
> Marek Florianczyk <[EMAIL PROTECTED]> wrote:
>
>> fsync = false
>
> HOLD THE BOAT THERE BATMAN!
>
> I would *STRONGLY* advise not running with fsync=false in production as
> PG _CANNOT_ guaruntee data consistancy
scott.marlowe wrote:
Note that if you're on an IDE drive and you haven't disabled the write
cache, you may as well turn off fsync as well, as it's just getting in the
way and doing nothing, i.e. the IDE drives are already lying about fsync
so why bother.
What about Serial ATA?
-
Hi,
Christopher Browne wrote, On 11/6/2003 4:40 PM:
[EMAIL PROTECTED] (Jeff) writes:
On 06 Nov 2003 15:21:03 +0100
Marek Florianczyk <[EMAIL PROTECTED]> wrote:
fsync = false
HOLD THE BOAT THERE BATMAN!
I would *STRONGLY* advise not running with fsync=false in production as
PG
David Green wrote:
Marek Florianczyk wrote, on Thursday, 11/06/03:
... And my management says, that there is no good support for Open
Source, heh... ;)))
In my experience, there is better support for Open Source than
Closed Source when it comes to development (and usually all around).
On 6 Nov 2003, Marek Florianczyk wrote:
>
> ... And my management says, that there is no good support for Open
> Source, heh... ;)))
That's because your "support" needs are different. A developer wants
answers and solutions, a manager often wants someone to blame. :-)
---
Marek Florianczyk wrote, on Thursday, 11/06/03:
>
>... And my management says, that there is no good support for Open
>Source, heh... ;)))
In my experience, there is better support for Open Source than
Closed Source when it comes to development (and usually all around).
David Green
Sage Automa
On Thu, 6 Nov 2003, Jeff wrote:
> On 06 Nov 2003 15:21:03 +0100
> Marek Florianczyk <[EMAIL PROTECTED]> wrote:
>
>
> > fsync = false
>
> HOLD THE BOAT THERE BATMAN!
>
> I would *STRONGLY* advise not running with fsync=false in production as
> PG _CANNOT_ guaruntee data consi
Marek Florianczyk <[EMAIL PROTECTED]> writes:
> W li¶cie z czw, 06-11-2003, godz. 15:37, Jeff pisze:
>> I would *STRONGLY* advise not running with fsync=false in production as
>> PG _CANNOT_ guaruntee data consistancy in the event of a hardware
>> failure. It would sure suck to have a power failu
W liście z czw, 06-11-2003, godz. 15:37, Jeff pisze:
> On 06 Nov 2003 15:21:03 +0100
> Marek Florianczyk <[EMAIL PROTECTED]> wrote:
>
>
> > fsync = false
>
> HOLD THE BOAT THERE BATMAN!
>
> I would *STRONGLY* advise not running with fsync=false in production as
> PG _CANNOT_
1 - 100 of 210 matches
Mail list logo
