Many thanks for all your advice and we will use Greg Smith's book on
performance to incrementaly tune our environment.
Regards,
Lawrence Cohan.
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: April-21-11 3:38 PM
To: pgsql-bugs@postgresql.org; Law
kpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
checkpoint_warning = 60s# 0 disables
Best regards,
Lawrence Cohan.
-Original Message-
From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org]
On Behalf Of Kevin Grittne
and I will post back real
time results as soon as I can get them done in production servers.
Regards,
Lawrence Cohan.
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: April-01-11 10:38 AM
To: Greg Stark
Cc: pgsql-bugs@postgresql.org; Lawrence Cohan
S
Thank you for all your suggestions - will attempt to make changes as
recommended one at a time and will post back the results.
Regards,
Lawrence Cohan.
-Original Message-
From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org]
On Behalf Of Kevin Grittner
Sent
7;syslog'
'log_line_prefix';'user=%u,db=%d '
'log_min_duration_statement';'1s'
'maintenance_work_mem';'256MB'
'max_connections';'1200'
'max_stack_depth';'2MB'
'port';'5432'
'server
below. As you can see
we picked a simple query with INNER JOIN between two indexed tables where
postgres 8.3 and 9.0 decides to not use existing indexes for whatever reason.
select oi.id from order_items oi inner join clients_orders co on
oi.order_id = co.id;
Lawrence Cohan
We thank you for the links that have a lots of info and please note that we
tuned our servers as recommended by Enterprise DB experts while they were in
house for our hardware/software migrations and the setting you mentioned are in
place already.
Regards,
Lawrence Cohan.
-Original
Please see results attached before and after the vacuum and note they are taken
from version 9.0
As regular maintenance we reindex/vacuum/analyze entire database once a week
and run ANALYZE against it every few hours.
Lawrence Cohan.
-Original Message-
From: Pavel Stehule
f the queries we
will execute on a regular basis. It forces the planner to prefer indexes. I've
also noticed that limit behavior which is sort of puzzling to me.
From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org]
On Behalf Of Lawrence Cohan
Sent: Wednesday, March 30,
We have a huge performance issues in Postgres that surfaced due to existing
indexes not being used like in the example below in both 8.35 and 9.0 versions.
Client_Orders table with and int ID as PK which is the order_id and indexed -
about 155,000 rows
Order_Items table with and int ID primary k
milliseconds on any searched string.
Best regards,
Lawrence Cohan.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2008 9:31 PM
To: Lawrence Cohan
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4351: Full text search performance
"Lawrence
The following bug has been logged online:
Bug reference: 4351
Logged by: Lawrence Cohan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Linux Red Hat 5.1
Description:Full text search performance
Details:
-- We are about to use full text
It is not criticism but only my own thought and PG is a really great
database!!! It was all perhaps due to my poor understanding of
relhasindex from pg_class internal catalog and I understand and respect
your view.
Best regards,
Lawrence Cohan.
-Original Message-
From: Tom Lane [mailto
Many thanks again. I figured out how to get only the tables that have
indexes created less these PK indexes so I can used the pg_get_indexdef
to rebuild them all through a scheduled Pgagent job in a loop using
CONCURRENTLY as our production assumes DB access 24/7.
Lawrence Cohan.
-Original
from pg_class where relname = 'foo';
-
t
(1 row)
drop table foo;
Many thanks,
Lawrence Cohan.
-----Original Message-
From: Lawrence Cohan
Sent: Friday, June 13, 2008 11:57 AM
To: 'Tom Lane'
Cc: pgsql-bugs@postgresql.org
Subject: RE: [BUGS] BUG #4238: pg_c
r dropped unless you will drop the Pkey.
In that case the two separate pg_class relhasindex and relhaspkey would
make sense indeed - just a thought nothing else and we'll take it as is.
Best regards,
Lawrence Cohan.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent
on
we are on in production is 8.2.5 not 8.3 yet.
Thanks,
Lawrence Cohan.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2008 11:44 AM
To: Lawrence Cohan
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4238: pg_class.relhasindex not updated by
vac
The following bug has been logged online:
Bug reference: 4238
Logged by: Lawrence Cohan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux 4.1.1
Description:pg_class.relhasindex not updated by vacuum
Details:
We rely on this column
The following bug has been logged online:
Bug reference: 4234
Logged by: Lawrence Cohan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux 4.1.1
Description:VACUUM dies in without error in a PGAgent job
Details:
We are using PGAgent
or an upgrade.
Lawrence Cohan.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 4:58 PM
To: Lawrence Cohan
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4232: CREATE INDEX CONCURRENTLY
"Lawrence Cohan" <[EMAIL PROTECTED]>
The following bug has been logged online:
Bug reference: 4232
Logged by: Lawrence Cohan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Redhat Linux 4.1.1
Description:CREATE INDEX CONCURRENTLY
Details:
We must run maintenance tasks like
hen vacuum/analyze/reindex/analyze and even after that
the results were the same. I just tried your suggestion and IT WORKED!
Thanks a lot again,
Lawrence Cohan.
-Original Message-
From: hubert depesz lubaczewski [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2008 2:41 PM
To: Lawrence Cohan
The following bug has been logged online:
Bug reference: 4224
Logged by: Lawrence Cohan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: red hat 4.1.1-52
Description:issue with LIMIT and ORDER BY
Details:
Following queries run FOREVER in
23 matches
Mail list logo
