On Fri, Mar 10, 2006 at 08:11:44AM +0100, NbForYou wrote:
As you can see the query isn't useful anymore because of the
processtime. Please Also notice that both systems use a different
query plan.
Also on the webhost we have a loop of 162409 (403 rows * 403 rows).
Both systems also use a
Hey Michael, you sure know your stuff!
Versions:
PostgreSQL 7.3.9-RH running on the webhost.
PostgreSQL 8.0.3 running on my homeserver.
So the only solution is to ask my webhost to upgrade its postgresql?
The question is will he do that? After all a license fee is required for
commercial use.
Is it possible to get a stack trace from the stuck process?
I dunno
if you've got anything gdb-equivalent under Windows, but that's the
first thing I'd be interested in ...
Here ya go:
http://www.devisser-siderius.com/stack1.jpg
http://www.devisser-siderius.com/stack2.jpg
On 10.03.2006, at 10:11 Uhr, NbForYou wrote:
So the only solution is to ask my webhost to upgrade its postgresql?
Seems to be.
The question is will he do that?
You are the customer. If they don't, go to another provider.
After all a license fee is required for
commercial use. And
On fös, 2006-03-10 at 10:11 +0100, NbForYou wrote:
Hey Michael, you sure know your stuff!
Versions:
PostgreSQL 7.3.9-RH running on the webhost.
PostgreSQL 8.0.3 running on my homeserver.
So the only solution is to ask my webhost to upgrade its postgresql?
The question is will he do
Hello list.
We have compared 2 IBM x
servers:
IBM
X206
IBM X226
--
---
processor
Pentium 4 3.2
Ghz
Xeon 3.0 Ghz
main
memory
1.25
GB
4 GB
discs
2 x SCSI
RAID11RPM
1 x ATA 7200 RPM
LINUX
2.6 (SUSE
9)
same
PGSQL
7.4same
Hi,
I think im specting problems with a 7.4.8 postgres database.
Sometimes some big query takes between 5 to 15 seconds. It happens
sometimes all the day it does not depend if database is busy.
I have measured that sentence in 15 - 70 ms in normal circunstances.
Why sometimes its takes too
NbForYou wrote:
Hey Michael, you sure know your stuff!
Versions:
PostgreSQL 7.3.9-RH running on the webhost.
PostgreSQL 8.0.3 running on my homeserver.
So the only solution is to ask my webhost to upgrade its postgresql?
The question is will he do that? After all a license fee is required for
There is not possibility to use another database. It's the best option I
have seen. We have been working in postgres in last 3 years, and this is
the first problem I have seen. (The database is working in a large
website, 6.000 visits per day in a dedicated server)
Any other idea?
Chethana,
Ok, Everybody keeps saying that Postgresql is free...
So I contacted my webhost and their respons was they have to pay a license
fee.
But because they use PLESK as a service I think they are refering to a fee
PLESK charges them
for the use combination PLESK - POSTGRESQL
I do not know
On Fri, Mar 10, 2006 at 11:05:57AM +0100, Ruben Rubio Rey wrote:
Sometimes some big query takes between 5 to 15 seconds. It happens
sometimes all the day it does not depend if database is busy.
I have measured that sentence in 15 - 70 ms in normal circunstances.
Is it the *exact* same
Ok, Everybody keeps saying that Postgresql is free...
So I contacted my webhost and their respons was they have to pay a
license fee.
But because they use PLESK as a service I think they are refering to a
fee PLESK charges them
for the use combination PLESK - POSTGRESQL
Michael Fuhr wrote:
On Fri, Mar 10, 2006 at 11:05:57AM +0100, Ruben Rubio Rey wrote:
Sometimes some big query takes between 5 to 15 seconds. It happens
sometimes all the day it does not depend if database is busy.
I have measured that sentence in 15 - 70 ms in normal circunstances.
On Friday 10 March 2006 04:20, Magnus Hagander wrote:
Is it possible to get a stack trace from the stuck process?
I dunno
if you've got anything gdb-equivalent under Windows, but that's the
first thing I'd be interested in ...
Here ya go:
H.J. Sanders wrote:
X206 IBM X226
-----
processorPentium 4 3.2
GhzXeon 3.0 Ghz
main memory1.25
GB
Ruben Rubio Rey wrote:
Hi,
I think im specting problems with a 7.4.8 postgres database.
Sometimes some big query takes between 5 to 15 seconds. It happens
sometimes all the day it does not depend if database is busy.
I have measured that sentence in 15 - 70 ms in normal circunstances.
Why
The primary slow down is probably between your system bus from main
memory to your disk storage. If you notice from your statistics that
the select statements are very close. This is because all the data you
need is already in system memory. The primary bottle neck is probably
disk I/O. Scsi will
Hi,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Thursday, March 09, 2006 9:11 PM
To: Jan de Visser
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Hanging queries on dual CPU windows
Jan de Visser [EMAIL
On Friday 10 March 2006 09:03, Jan de Visser wrote:
On Friday 10 March 2006 04:20, Magnus Hagander wrote:
Is it possible to get a stack trace from the stuck process?
I dunno
if you've got anything gdb-equivalent under Windows, but that's the
first thing I'd be interested in
On Friday 10 March 2006 09:32, Jan de Visser wrote:
Actually, stack2 looks very interesting. Does it stay stuck in
pg_queue_signal? That's really not supposed to happen.
Yes it does.
An update on that: There is actually *two* processes in this state, both
hanging in pg_queue_signal.
I dunno
if you've got anything gdb-equivalent under Windows,
but that's
the first thing I'd be interested in ...
Here ya go:
http://www.devisser-siderius.com/stack1.jpg
http://www.devisser-siderius.com/stack2.jpg
On Thu, Mar 09, 2006 at 08:13:30AM -0500, mcelroy, tim wrote:
charts showing system and in this case DB performance. I'm basically just
using the out-of-the-box defaults in my postgresql.conf file and that seems
Ugh... the default config won't get you far. Take a look here:
See also
http://www.jonathangardner.net/PostgreSQL/materialized_views/matviews.html
On Fri, Mar 10, 2006 at 02:25:08AM +, Casey Allen Shobe wrote:
I typed up a description of a situation where the only viable option to
improve performance was to use a materialized view, which, when
On Fri, Mar 10, 2006 at 11:29:53AM +0100, Ruben Rubio Rey wrote:
There is not possibility to use another database. It's the best option I
have seen. We have been working in postgres in last 3 years, and this is
the first problem I have seen. (The database is working in a large
website,
On Friday 10 March 2006 10:11, Magnus Hagander wrote:
Could it be they broke it when they did that
In theory, yes, but it still seems a bit far fetched :-(
Well, I rolled back SP1 and am running my test again. Looking much better,
hasn't locked up in 45mins now, whereas before it would
Hello.
Recently I've discovered an interesting thing (Postgres version 8.1.3):
example table:
CREATE TABLE test (
id INT,
name TEXT,
comment TEXT,
phone TEXT,
visible BOOLEAN
);
then,
CREATE INDEX i1 ON test(phone);
CREATE INDEX i2 ON test(phone, visible);
CREATE INDEX i3 ON test(phone,
On Fri, 2006-03-10 at 04:45, NbForYou wrote:
Ok, Everybody keeps saying that Postgresql is free...
So I contacted my webhost and their respons was they have to pay a license
fee.
But because they use PLESK as a service I think they are refering to a fee
PLESK charges them
for the use
Evgeny Gridasov [EMAIL PROTECTED] writes:
Recently I've discovered an interesting thing (Postgres version 8.1.3):
Have you ANALYZEd the table since loading it? What fraction of the rows
have visible = true?
regards, tom lane
---(end of
Tom,
ofcourse I've analyzed it.
visible is true for about 0.3% of all rows.
testing table contains about 300,000-500,000 rows.
On Fri, 10 Mar 2006 12:09:19 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Evgeny Gridasov [EMAIL PROTECTED] writes:
Recently I've discovered an interesting thing
We have large tables that hold statistics based on time. They are of the
form.
CREATE TABLE stats (
id serial primary key,
logtime timestamptz,
d1 int,
s1 bigint
);
CREATE INDEX idx on stats(logtime);
Some of these tables have new data inserted at a rate of 500,000+ rows /
Could it be they broke it when they did that
In theory, yes, but it still seems a bit far fetched :-(
Well, I rolled back SP1 and am running my test again. Looking
much better, hasn't locked up in 45mins now, whereas before
it would lock up within 5mins.
So I think they broke
Evgeny Gridasov [EMAIL PROTECTED] writes:
ofcourse I've analyzed it.
visible is true for about 0.3% of all rows.
Well, I get an indexscan on i3 ... there isn't going to be any
strong reason for the planner to prefer i2 over i1, given that
the phone column is probably near-unique and the i2
On Friday 10 March 2006 13:25, Magnus Hagander wrote:
Could it be they broke it when they did that
In theory, yes, but it still seems a bit far fetched :-(
Well, I rolled back SP1 and am running my test again. Looking
much better, hasn't locked up in 45mins now, whereas before
On Friday 10 March 2006 14:27, Jan de Visser wrote:
As a BTW: I reinstalled SP1 and turned stats collection off. That also
seems to work, but is not really a solution since we want to use
autovacuuming.
I lied. I hangs now. Just takes a lot longer...
jan
--
Marc Morin [EMAIL PROTECTED] writes:
We tend to analyze these tables every day or so and this doesn't always
prove to be sufficient
Seems to me you just stated your problem. Instead of having the planner
make wild extrapolations, why not set up a cron job to analyze these
tables more
Well this analyze just took 12 minutes... Stats target of 100.
# time psql xxx xxx -c analyze elem_trafficstats_1
ANALYZE
real12m1.070s
user0m0.001s
sys 0m0.015s
A large table, but by far, not the largest... Have about 1 dozen or so
tables like this, so analyzing them will take
Hello,
I got good results on tuning postgresql performance for my friend.
One of the queries took almost 10 minutes.
Now it completes on 26 miliseconds! (at the second run)
A combination of query otimization, indexes choosing (with some droping
and clustering), server parameters
On Fri, 2006-03-10 at 13:40 +, Richard Huxton wrote:
Your ATA disk is lying about disk caching being turned off. Assuming
each insert is in a separate transaction, then it's not going to do
10,000 / 6 = 1667 transactions/sec - that's faster than it's rotational
speed.
Could you explain
On Sat, 11 Mar 2006, Joost Kraaijeveld wrote:
On Fri, 2006-03-10 at 13:40 +, Richard Huxton wrote:
Your ATA disk is lying about disk caching being turned off. Assuming
each insert is in a separate transaction, then it's not going to do
10,000 / 6 = 1667 transactions/sec - that's faster
39 matches
Mail list logo
