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. A
> > 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.
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 running
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 h
Hello list.
We have compared 2 IBM x
servers:
IBM
X206
IBM X226
--
---
processor
Pentium 4 3.
Hello
list.
Reading my
own e-mail I notice I made a very important mistake.
The
X206 has 1 x ATA 7200 RPM
The X226
has 2 x SCSI
RAID1 1RPM
I corrected
it below.
Sorry
.
Henk
Sanders
-Oorspronkelijk
bericht-Van: [EMAIL PROTECTED]
[mailto:[E
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 m
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 howeve
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 qu
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
Probab
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:
> >
> > http://www.de
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 s
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 a
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 <[EM
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
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_q
> > > > 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:
http://www.powerpo
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 implem
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, 6
On 3/10/06, NbForYou <[EMAIL PROTECTED]> 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 t
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 woul
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, vi
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 th
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 broadca
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 (P
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 /
hour
> > > 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
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 i
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,
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
"Marc Morin" <[EMAIL PROTECTED]> writes:
> Well this analyze just took 12 minutes... Stats target of 100.
> # time psql xxx xxx -c "analyze elem_trafficstats_1"
Try analyzing just the one column, and try reducing its stats target to
10. It does make a difference:
sorttest=# set default_statisti
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 reconfigurations.
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 expla
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 than
42 matches
Mail list logo
